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ABSTRACT 


This  is  a  report  of  the  work  performed  by  the  General  Research 
Corporation  during  the  Advanced  Software  Quality  Assurance  contract. 
Research  was  conducted  in  four  major  areas: 

1.  Assertions,  verification  conditions  and  consistency  proof 

2.  Design  of  an  executable  assertion  language  and  the 
development  of  a  preprocessor  to  implement  this  language 

3.  Development  of  a  Software  Quality  Laboratory 

4.  Evaluation  of  existing  languages  as  applied  to  BMD  software 
problems 

This  report  gives  a  methodology  for  verifying  software.  The  preprocessors 
which  allow  assertions  to  be  placed  in  FORTRAN  and  PASCAL  programs  are 
described.  The  static  analyses  developed  as  part  of  the  Software  Quality 
Laboratory  are  also  described  and  examples  are  given  of  their  use.  The 
Concurrent  PASCAL  programming  language  is  applied  to  a  generic  model  of  a 
BMD  software  system. 


I 


SECTION 


CONTENTS 


ABSTRACT 


INTRODUCTION 


1.1  Background 

1.2  Accomplishments 

1.3  Report  Organization 

METHODOLOGY  FOR  VERIFICATION 

2.1  Recommendations 

2.2  Verification  Without  Redundancy 

2.3  Verification  With  Redundancy 

LANGUAGE  EXTENSIONS  AND  IMPROVEMENTS 

3.1  Improved  Control  Structures 

3.2  Executable  Assertions 

3.3  Data  Access  Statements 

3.4  Physical  Units  Statements 

3.5  Implementation  of  Verifiable  PASCAL 

STATIC  ANALYSIS 

4.1  Static  Analysis  Commands  and  Reports 

4.2  Physical  Units  Consistency  Analysis 

4.3  Data  Flow  Analysis 

EXECUTION 

5.1  Coverage  Reports 

5.2  Assertions 

5.3  Fault  Detection 

FORMAL  VERIFICATION 
6.1  Verification  Tools 


CONTENTS  (Contd.) 


SECTION  _  PAGE 

6.2  Interactive  Assistance  137 

6.3  Verified  Programs  1A7 

7  SOFTWARE  DEVELOPMENT  SYSTEM  QUALITY  ASSESSMENT  151 

7.1  The  Applicability  of  Concurrent  PASCAL  to 

BMD  Software  151 

7.2  Classes  of  Concurrency  160 

7.3  Assertions  for  Concurrent  PASCAL  Monitors  163 

APPENDIX  A  GRAMMAR  DESCRIPTION  FOR  VERIFIABLE  PASCAL  A-1 

i.- 

APPENDIX  B  TRANSLATION  TEMPLATES  FOR  VERIFIABLE  PASCAL  B-1 

APPENDIX  C  TRANSLATION  TEMPLATES  FOR  IFTRAN  WITH  ASSERTIONS  C-1 

APPENDIX  D  VERIFIED  PROGRAMS  D-1 

REFERENCES  R-1 


t 


ILLUSTRATIONS 


f 

t 


NO. _ PAGE 


2.1  Steps  in  Verification  Procedure  6 

3.1  Example  Showing  Use  of  IFTRAN  Language  Extensions  23 

3.2  Example  Showing  Use  of  PASCAL  Language  Extensions  24 

3.3  IF. . .ORIF. . .ELSE. . .END  IF  Construct  27 

3.4  WHILE. . .END  WHILE  Contruct  29 

3.5  DO. ..END  DO  Construct  30 

3.6  REPEAT. . .UNTIL  Construct  31 

3.7  LOOP... EXIT  IF... END  LOOP  Construct  33 

3.8  LOOP ... EXIT ...  END  Loop  Construct  34 

3.9  FOR... END  FOR  V71th  TO  and  UNTIL  Clauses  38 

3.10  BLOCK... END  BLOCK  and  INVOKE  Construct  39 

3.11  PASCAL  Statements  for  Control  Structures  46 

3.12  Syntax  Diagrams  for  Control  Structures  47 

3.13  Example  Showing  Improved  PASCAL  Control  Structures  49 

3.14  PASCAL  Statements  for  Assertions  35 

3.15  Syntax  Diagram  for  PASCAL  Assertions  56 

3.16  Data  Access  Statements  for  PASCAL  60 

3.17  Syntax  Diagrams  for  PASCAL  Data  Access  Statements  60 

3.18  UNITS  Qualification  for  PASCAL  62 

3.19  Syntax  Diagrams  for  PASCAL  UNITs  Statements  63 

3.20  Example  of  Constant  Definition  Part  with  Units  Defined  64 

3.21  Example  of  Type  Definition  Part  with  Units  Defined  64 

3.22  Example  of  Input  Text  Listing  from  Verifiable  PASCAL 

Preprocessor  68 

3.23  Example  of  Translated  Text  Produced  by  Verifiable  PASCAL 

Preprocessor  69 

*  f 

3.24  Example  of  Indented  Source  Listing  from  Verifiable 

PASCAL  Preprocessor  70 


V 


ILLUSTRATIONS  (Contd.) 


NO. 

PAGE 

3.25 

Example  of  Source  Text  Directory  and  Module  Structure 

Report 

71 

A.l 

Symbol  Analysis  Summary 

77 

4.2 

Units  Error  Report  due  to  Incorrect  Units 

78 

4.3 

Units  Error  Report  due  to  Misspelling 

78 

4.4 

Units  Error  due  to  Mismatched  Parameter/Argument 

79 

4.5 

Subroutine  SETUSE  Statement  Listing 

81 

4.6 

Symbol  Analysis  Summary  with  Uninitialized  Variables  Errors 

81 

4.7 

Statement  Listing  for  CIRCLE 

83 

4.8 

Statement  Listing  for  ARITH 

85 

4.9 

Symbol  Analysis  Summary  with  Variable  Use  Assertion  Errors 

85 

4.10 

Statement  Listing  for  Subroutine  MODE 

87 

4.11 

Statement  Analysis  Summary  with  Mode  Warnings 

87 

4.12 

Statement  Listing:  Subroutine  CIRCLE 

89 

4.13 

Statement  Listing:  Subroutine  ARITH 

89 

4.14 

Statement  Analysis  Summary  Showing  Calling  Errors 

90 

4.15 

Statement  Listing  of  Subroutine  NOPATH 

91 

4.16 

Statement  Analysis  Summary  with  Unreachable  Statement 

Errors 

91 

4.17 

Statement  Listing  of  Subroutine  SEARCH 

93 

4.18 

Loop  Analysis  Warning  Report 

93 

4.19 

Physical  Units  Tree 

95 

4.20 

Physical  Units  Simplification  Rules 

96 

4.21 

Physical  Units  Normalization  Rules 

97 

4.22 

Physical  Units  Consistency  Analysis  Algorithm 

98 

4.23 

Basic  Structured  Forms 

104 

4.24 

Data  Flow  Analysis  Algorithm 

105 

5.1 

Instrumented  Modules 

108 

5.2 

Summary  Report  for  Test  of  Search  and  Track 

111 

5.3 

Detailed  Reports 

113 

6.1 

DD-Path  Definitions  for  Module  SIMPLE 

122 

6.2 

Verification  Path  Report  for  Module  SIMPLE 

123 

vl 


ILLUSTRATIONS  (Contd) 


NO. _ 

6.3  Verification  Condition  Report  for  Module  SIMPLE 

6.4  Simplifier  Tree 

6.5  DIV  Subroutine  with  Trail  Loop  Invariant 

6.6  Loop  Verification  Condition  Using  Trail  Loop  Invariant 

6.7  Interactive  Program  Proving 

6 . 8  Command  Menu 

6.9  SIMPLIFY  Command 

6.10  Enter  PATH 

6.11  Report  from  Path  Command 

7.1  Monitor  for  Search  Return  Data  Set 

7.2  Search  Return  Processing  in  OilM 

7.3  Assimilate  Radar  Returns  Process 

7.4  Generate  Verify  Pulse  Process 

7.5  Radar  Activity  Processing  in  GSIM 

7.6  Track  Processing  in  GSIM 

7.7  Dimensions  of  Concurrent  Processing  Problems 

7.8  Problems  in  Concurrent  Processing 

7.9  Classification  of  Concurrency  in  GSIM 

7.10  GSIM  Process  and  Data  Structures 

7.11  Search  Return  Data  Set  Monitor  with  Comments 

7.12  Assertions  for  DELAY  and  CONTINUE  Statements 

7.13  SRDS  Monitor  with  Assertions 


vli 


a-**'’ 


PAGE 

123 

126 

136 

138 

139 

142 

143 

144 

145 
152 

154 

155 

156 
158 
160 
161 
162 

164 

165 
168 

170 

171 


ir 

4 


1 


INTRODUCTION 


In  the  current  contract,  GRC's  work  in  advanced  quality  assurance 
was  concentrated  on  developing  a  capability  for  the  formal  verification 
of  large  real-time  systems.  It  was  found  in  the  course  of  this  work 
that  some  techniques  useful  in  the  formal  verification  process  are  also 
applicable  to  the  problem  of  detecting  errors  arising  from  erroneous 
sensor  data  or  hardware  failures.  In  addition,  languages  that  appear  to 
promise  higher  software  quality  were  evaluated. 

1.1  BACKGROUND 

This  effort  was  an  outgrowth  of  an  initial  study,  the  Reliable 
1  2 

Software  Study,  ’  which  suggested  a  number  of  techniques  that  could  lead 
to  improved  software.  Emphasis  has  been  placed  on  techniques  that  orl- 

3  4  5 

glnated  with  Floyd,  ’  were  shown  to  be  useful  by  King,  and  further 
developed  by  others.^  ^  Specific  costly  errors,  such  as  those  described 
by  Osterwell  and  Fosdlck^^  and  In  a  study  by  Loglcon,^^  were  also 
addressed. 

f 

Since  the  effort  was  directed  towards  the  verification  of  real-time 
programs,  it  was  decided  that  the  target  languages  should  be  "real."  By 
real,  It  is  meant  that  a  compiler  exists  for  the  language  such  that  a 
program  written  in  it  can  execute  normally  on  a  machine.  This  is  a  strong 
criterion  that  most  others  have  not  chosen  to  meet.  The  target  languages 
were  FORTRAN  and  PASCAL.  As  far  as  the  techniques  are  concerned,  their 
analysis  appears  very  similar,  requiring  only  separate  front  ends.  Each 
of  the  languages  has  a  dialect—IFTRAN  for  FORTRAN  and  Verifiable  PASCAL 
for  PASCAL.  Preprocessors  were  developed  to  generate  standard  FORTRAN 
from  IFTRAN  and  standard  PASCAL^^  from  Verifiable  PASCAL.  The  resulting 
programs  execute  on  computers  such  as  the  CDC  6400  and  CDC  7600  which 
have  standard  compilers. 

The  system  that  actually  performs  the  analysis  was  built  using 
IFTRAN. 

§ 
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1.2  ACCOMPLISHMENTS 

GRC's  work  has!  resulted  in  the  establishment  of  the  Software  Quality 
Laboratory.  This  facility  contains  tools  which  can  be  used  to  detect 
common  semantic  errors,  assist  in  testing,  formally  verify  computer 
programs,  and  provide  for  fault  tolerance. 

The  facility  has  been  designed  to  analyze  both  FORTRAN  and  PASCAL. 
Extensions  to  both  these  languages  have  been  designed  and  implemented  so 
that  common  errors  can  be  detected  and  formal  verification  is  possible. 

The  languages  with  their  extensions  have  been  translated  into  exe¬ 
cutable  code.  The  redundancy  preseat  in  the  executable  extensions  provides 
for  the  detection  of  errors  during  program  execution.  This  capability  will 
be  used  in  future  work  in  fault  tolerance. 


Since  one  of  the  goals  of  this  work  has  been  to  apply  formal  verifi¬ 
cation  to  practical  programs,  verification  condition  generators  were  <>■ 

Implemented  for  both  languages.  The  generators  handle  logical,  fixed 
point,  character,  and  floating-point  data  types.  Multidimension  arrays 
are  presently  handled  and  PASCAL  records  will  be  handled  in  the  near 
future. 


The  verification  process  divides  programs  into  very  small  segments 
each  of  which  is  verified  independently  of  all  other  parts.  Each  verifi¬ 
cation  condition  is  tightly  coupled  to  the  code  segment  with  which  it  is 
associated.  Both  the  code  segment  and  the  verification  condition  can  be 
listed  on  a  printer  and/or  displayed  on  an  interactive  terminal. 

A  simplifier  which  contains  many  standard  simplification  rules  can 
be  Invoked  to  cause  automatic  simplification  of  verification  conditions. 

Rules  which  are  not  in  the  simplifier  can  be  applied  to  individual 
verification  conditions.  These  rules  can  be  text  replacement  rules  or 
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pattern  matching  rules.  They  can  be  applied  only  once  or  saved  as  an 
axiom  to  be  used  agaiCk. 

We  have  also  looked  at  the  classes  of  concurrency  present  in  a 
BMD  system  and  at  the  possibility  of  using  Co’  current  PAkSCAL  as  a 
language  for  a  BMD  software  system.  The  advantages  and  disadvantages 
of  Concurrent  PASCAL  for  this  application  have  been  noted. 

1.3  REPORT  ORGANIZATION 

Section  2  outlines  how  to  prepare  software  for  verification.  It 
contains  an  overall  description  of  the  Software  Quality  Laboratory,  with 
some  examples  of  how  the  various  parts  can  be  used  to  validate  software. 

It  also  contains  a  set  of  recommendations  for  the  development  of  quality 
software.  These  have  resulted  from  our  experience  with  the  techniques 
discussed  in  this  report. 

Section  3  describes  the  language  extensions  that  were  made  to  FORTRAN 
and  PASCAL  so  that  the  software  written  in  those  languages  could  be 
verified.  Section  3  emphasizes  the  translation  of  the  extensions  into 
executable  code.  These  same  languages  are  the  ones  for  which  the  static 
analysis  tools  and  formal  verification  techniques  are  available. 

Section  4  describes  techniques  that  can  be  used  to  remove  errors 
before  a  complete  verification  can  be  completed.  These  techniques  could 
be  Implemented  in  a  super-compiler.  However,  they  were  implemented  in  a 
separate  process  which  allowed  this  work  not  to  duplicate  the  compiler, 
allowed  the  assumption  that  syntax  errors  had  been  removed,  and  provided 
data  which  was  used  later  in  the  formal  verification  process. 

Section  5  shows  how  quality  can  be  Improved  in  the  testing  process 
through  the  use  of  coverage  tests  and  executable  assertions.  Also  Included 
is  a  discussion  as  to  how  the  executable  assertions  can  be  used  to  derive 
loop  invariants  and  to  detect  faults  at  execution  time. 


Section  6  Is  concerned  with  the  formal  verification  process.  Once 
software  has  been  shown  to  be  free  of  syntax  and  major  categories  of 
semantic  errors  using  the  techniques  described  in  previous  sections,  it 
is  ready  for  formal  verification.  This  section  describes  the  process  of 
verification  from  the  design  and  implementation  of  the  verification 
condition  generator  and  simplifier  to  examples  of  validated  programs. 

Section  7  discusses  the  possible  application  of  Concurrent  PASCAL 
to  a  large  software  system.  The  advantages  of  and  disadvantages  of 
Concurrent  PASCAL  are  demonstrated  with  an  example  of  its  application  to 
a  real-time  simulation  program.  The  types  of  concurrency  which  are 
present  in  a  BMD  system  are  presented,  and  assertions  for  such  programs 
are  given. 

Appendixes  are  provided  to  describe  the  formal  grammar  of  Verifiable 
PASCAL  (Appendix  A) ,  the  translation  templates  for  the  generation  of 
PASCAL  from  Verifiable  PASCAL  (Appendix  B) ,  the  translation  templates 
for  the  generation  of  FORTRAN  from  IFTRAN  with  assertions  (Appendix  C), 
and  the  formal  verification  of  sample  programs  (Appendix  D) . 
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METHODOLOGY  FOR  VERIFICATION 


As  the  Software  Quality  Laboratory  evolved,  it  became  obvious  that 
it  was  not  possible  to  verify  software  that  had  not  been  written  with 
verification  in  mind.  This  section  outlines  how  software  can  be  prepared 
for  the  verification  process,  shows  what  can  be  accomplished  through 
several  stages  of  verification,  and  how  the  tools  available  for  proofs  of 
correctness  can  be  used  to  provide  designed- in  quality.  The  various 
steps  in  this  verification  procedure  are  shown  in  Fig.  2.1. 


2.1  RECOMMENDATIONS 

Based  upon  GRC’s  experience  to  date  in  the  development  and  use  of 
the  Software  Quality  Laboratory,  the  following  recommendations,  which 
should  lead  to  higher  quality  software,  are  made: 

1.  Use  small  modules.  Designs  that  use  small  modules  with  as 
few  global  variables  and  paths  as  possible  will  aid  the 
verification  process. 

2.  State  data  access  rights.  Every  global  variable  should  be 
declared  either  an  input,  output,  or  both. 

3.  Limit  variable  rights.  When  computationally  feasible,  keep 
inputs  separate  from  outputs. 

4.  State  units.  Every  variable  should  have  its  units  declared. 

5.  State  ranges.  Every  variable  should  have  its  range  of  values 
declared  at  module  entry  and  exit. 

6.  State  Invariants.  When  a  relation  between  variables  is  known 
to  be  always  true,  declare  that  relation.  Try  to  design 
algorithms  that  lend  themselves  to  relations  that  are  always 
true  rather  than  almost  always  true. 

7.  Place  constraints  on  results.  Every  output  variable  should  be 


bound  as  closely  as  possible  to  an  expression  in  terms  of  the 
input  variables. 
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Figure  2.1.  Steps  in  Verification  Procedure 
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8.  Use  tools  CO  eliminate  errors. 

a.  Use  static  analysis  tools  to  eliminate  unreasonable 
errors  before  testing  single  modules. 

b.  Make  sure  the  execution  test  step  checks  each  combination 
of  paths  in  a  module  before  integration. 

c.  Use  static  analysis  tools  to  check  module  interfaces 
before  testing  modules  together. 

d.  Turn  on  executable  assertions  during  execution  test. 

9.  Perform  formal  verification.  Use  assertions  developed  during 

testing  for  formal  verification. 

2.2  VERIFICATION  WITHOUT  REDUNDANCY 

The  key  characteristic  of  verifiable  software  is  redundant  informa¬ 
tion  that  is  provided  to  allow  a  checking  process  between  the  redundant 
inforjiation  and  the  software  itself.  This  Is  not  unlike  the  systems  used 
in  accounting  which  use  double  entries  to  provide  a  check.  If  there  is 
no  redundant  information,  there  is  little  that  can  be  done  to  verify  the 
software.  What  is  normally  done  Instead  is  to  run  a  set  of  test  cases 
for  which  answers  are  known.  Unfortunately,  the  testing  approach  cannot 
hope  to  completely  verify  large  programs  for  there  are  far  too  many 
possible  combinations  of  paths  through  them  and  too  many  possible  combina¬ 
tions  of  variables  to  ever  test  all  paths  with  all  values.  Since  existing 
systems  have  not  been  built  with  verifiable  software,  we  have  the  situation 
in  large  existing  programs  where  54%  of  the  errors  are  found  after  accept¬ 
ance  test  and  50%  of  the  life  cycle  cost  has  been  assigned  to  the  time 
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period  following  acceptance  tests.  This  time  period,  which  is  often 
named  the  "maintenance"  phase  of  the  project,  does  not  "maintain"  the 
software  in  its  delivered  state,  but  in  fact  tries  to  fix  the  errors  that 
are  found  after  the  software  should  be  error-free. 


There  are  a  few  valuable  checks  that  can  be  made  without  redundant 
information.  The  only  check  currently  in  use  by  most  developers  of  large 
systems  is  the  syntax  check  which  checks  that  every  statement  in  the  pro¬ 
gram  satisfies  the  rules  of  the  programming  language  used.  Statements 
that  do  not  satisfy  the  rules  are  designated  as  being  in  error,  and 
presented,  along  with  the  program  listing,  in  a  report  known  as  the 
diagnostic  report.  It  is  assumed  that  the  programmer  will  correct  these 
problems  before  proceeding.  As  a  result,  most  large  systems  today  pre¬ 
vent  the  programmer  from  testing  a  program  before  removing  the  syntax 
errors.  Since  syntax  errors  are  so  easy  to  detect  at  an  early  stage  in 
the  program  development,  they  are  not  regarded  as  serious  or  costly.  The 
Software  Quality  Laboratory  has  taken  the  approach  that  other  errors  (due 
to  an  unreasonable  sequence  of  statements)  should  also  be  reported  to  the 
programmer.  This  would  be  done  in  a  fashion  similar  to  the  diagnostics 
report  so  that  these  simple  (but  often  costly)  errors  can  be  removed  at 
the  same  time  as  the  syntax  errors  and  with  as  little  effort.  The  main 
difference  between  the  syntax  errors  detected  by  a  language  processor  and 
the  simple,  unreasonable  errors  found  by  the  Software  Quality  Laboratory 
is  that  a  sequence  of  statements  must  be  examined  rather  than  a  single 
statement.  These  errors  are  then  reported  in  terms  of  the  groups  of 
statements  that  could  have  caused  the  error,  rather  than  a  single  statement. 

The  unreasonable  errors  that  do  not  require  redundant  information 
are  the  set/use  errors,  mode  errors,  infinite  loop  errors,  external 
reference  errors,  and  unreachable  code  errors.  The  method  of  detecting 
and  reporting  each  of  these  errors  is  fully  described  in  Sec.  4.  This 
section  briefly  introduces  the  analysis  that  is  performed  by  means  of 
examples.  The  unreasonable  errors  are  removed  in  the  step  shown  in 
Fig.  2.1  labeled  STATIC  ANALYSIS.  This  step  is  done  after  the  syntax 
analysis. 


2.2.1  Set/Use  Errors 

Two  types  of  set/use  errors  are  detected.  One  of  the  most  common 

is  use  of  a  variable  before  it  is  set.  This  is  usually  due  to  forgetting 

to  Initialize  the  variable.  The  other  is  that  the  variable  is  set,  but 

is  not  used.  This  last  error  is  often  due  to  a  misspelling  of  the 

variable.  This  brief  program  demonstrates  some  common  set/use  errors  in 
IFTRAN  and  PASCAL. 


SUBROUTINE  AVER(A,  N,  ANS) 
INTEGER  N,  I,  J 
REAL  A(l),  ANS,  SUM 
J  -  1 

WHILE  (I  .LE.  N) 

SUM  -  SUM  +  A(I) 
I  -  I  +  1 
END  WHILE 

ANS  -  SUM/FLOAT(N) 
RETURN 


END 


PROCEDURE  aver  (VAR  a  :  ARRAY[l..n)  OF  real; 

VAR  ans  :  real) ; 

VAR  i,  j  :  Integer; 
sum  :  real; 

BEGIN 

j  :»  1; 

WHILE  i  <-  n  DO 

sum  :=  sum  +  a[ 1] ; 
i  1  +  1 
END  WHILE; 
ans  :»  sum/n 

END; 


IFTRAN  Set/Use  Errors 


V-PASCAL  Set /Use  Errors 


The  program  shows  three  set/use  errors  that  will  be  detected  by  the 
Software  Quality  LaUoratory.  The  variables  I  and  SUM  are  not  initialized, 
although  they  are  used  in  a  WHILE  loop,  and  the  variable  J  is  set  but  not 
used. 


2.2.2  Mode  Errors 

If  wc  had  the  statement 

ANS  -  SUM/N 

rather  than 

ANS  -  SUM/FTOAT(N) 
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a  mode  warning  would  be  produced  as  well,  since  real  and  Integer  variables 
should  not  appear  in  the  same  expression.  This  error  is  more  important 
in  the  multi-module  case  where  one  routine  interfaces  with  another,  as  in 
these  programs. 


PROGRAM  STAT( INPUT,  OUTPUT) 

INTEGER  DATA(IO),  1,  M,  N 
READER  »  5 
PRIN  -  6 
N  -  10 

READ  (READER,  1)(DATA(1),  I  -  1.  10) 
F0RMAT(I5) 

CALL  AVER (DATA.  N,  RESULT) 
WRITE(PRIN,  2)  RESULT 
FORMAT (F6. 2) 

STOP 

END 


PROGRAM  statdnput,  output); 

CONS  n  =  10; 

VAR  data  :  ARRAY[l..n]  OF  Integer; 
result  :  real; 

1,  m  :  Integer; 

(*PR0CEDURE  aver  goes  here*) 

BEGIN 

FOR  i  1  TO  n  DO 

readdnput,  datafl]) 
END  FOR; 

aver(dat3,  result); 
write(output ,  result) 

END. 


IFTRAN  Multi-Module  Mode  Error 


V-PASCAL  Multi-Module  Mode 
Error 


The  program  STAT  Invokes  AVER  to  calculate  the  average  of  ten  data 
values.  Unfortunately,  AVER  expects  that  the  data  is  real  while  STAT 
provides  Integer  data.  The  result,  of  course,  would  be  erroneous  if  the 
program  were  ever  executed. 


One  can  argue  that  some  modern  compilers,  notably  PASCAL,  provide 
this  facility  for  mode  checking.  To  do  so  they  require  that  every  module 
be  compiled  together.  As  a  result,  a  program  with  10^  lines  of  code  has 
not  been  written  using  such  languages.  The  static  analysis  facility  is 
concerned  with  the  analysis  of  systems  with  very  large  programs  (e.g., 

10^  lines  of  code),  hence  it  was  believed  important  to  provide  checking 
of  external  modules  after  syntax  errors  had  been  removed. 


2.2.3  External  Reference  Errors 

Another  costly  error  which  is  detectable  without  redundant  informa¬ 
tion  is  the  misuse  of  external  routines  with  the  incorrect  number  of 
parameters.  If,  for  example,  the  IFTRAN  CALL  statement  had  been 

CALL  AVER  (DATA,  N,  RESULT,  FLAG) 

or  the  V-PASCAL  statement  had  been 

aver  (data,  result,  flag); 

the  error  report  would  have  Indicated  that  the  external  routine  did  not 
have  the  same  number  of  parameters. 


2. 2.^4  Infinite  Loop  Errors 

Infinite  loops  often  result  because  on  one  path  the  control  variable 
to  exit  the  loop  was  not  modified.  If  this  is  the  case*,  an  error  report 
listing  the  problem  loop  is  given,  as  shown  below. 


WHILE  (M  .LT.  N) 

I  -  (M  +  N)/2 
IF  (X  .LT.  A(I)) 

N  -  I 

ORIF  (X  .GT.  A(I)) 
M  -  I 


WHILE  m  <  n  DO  , 

i,  :»  (m  +  n)  DIV  2; 
IF  X  <  a[l]  THEN 
.  n  ;■  I 

ORIF  X  >  a[l]  THEN 
m  :*  I 


ELSE 

LOOKUP  -  I 

END  IF 
END  WHILE 


ELSE 

lookup  :=  1 

ENDIF 
END  WHILE 


IFTRAN  Infinite  Loop  Error  V-PASCAL  Infinite  Loop  Error 


Once  entered,  the  above  loop  would  not  exit  if  X  is  equal  to  some 
element  in  the  array  A  between  A(M)  and  A(N)  since  neither  M  nor  N  is 
modified  once  that  element  is  found.  . 
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2.2.5  Unreachable  Code  Errors 


Another  costly  error  Is  unreachable  code.  This  Is  costly  because 
the  expense  of  designing,  preparing,  and  storing  the  code  could  have  been 
avoided  if  it  is  not  needed.  On  the  other  hand,  if  it  is  meant  to  exe¬ 
cute  under  some  circumstances,  then  the  fact  that  it  cannot  be  reached  is 
an  error.  Structurally  unreachable  code  is  most  common  in  large  unstruc¬ 
tured  programs  with  unconditional  transfers.  In  the  example  shown  below, 
statement  300  is  unreachable. 


REAL  FUNCTION  DISCR(A,  B,  C) 

FUNCTION  dlscr  (a,  b,  c  :  real)  : 

REAL  A,  B,  C,  D 

I  ABEL 

100,  200,  300,  400; 

D  -  A**2  -  4.0*B*C 

VAR  d 

:  real; 

IF  (D  .LT.  0.01 

BEGIN 

GO  TO  100 

d  a*a  -  4.0*b*c; 

ELSE 

IF  d  <  0.0  THE') 

GO  TO  200 

GOTO  100 

END  IF 

ELSE 

300 

DISCR  -  0.0 

GOTO  200 

GO  TO  400 

END  IF; 

100 

DISCR  -  -D 

300: 

dlscr  :•  0.0; 

GO  TO  400 

GOTO  400; 

200 

DISCR  -  0 

100: 

dlscr  :•  -d; 

400 

RETURN 

GOTO  400; 

END 

200: 

dlscr  ;«  d 

400:  END; 

IFTRAN 

Unreachable  Code 

V-PASCAL 

Unreachable  Code 

2.3  VERIFICATION  WITH  REDUNDANCY 

While  the  preceding  errors  can  be  found  without  the  need  for  redun¬ 
dant  Information,  the  errors  most  difficult  to  find  require  additional 
Information  specifically  for  program  verification.  The  elements  of  this 
information  are  known  collectively  as  assertions.  Every  assertion  added 
to  a  program  allows  checks  to  be  performed  that  can  eliminate  difficult- 


to-find  errors.  There  are  several  forms  of  assertions.  Some  are  rela¬ 
tively  easy  to  state  and  are  merely  the  concrete  expression  of  a  designer's 
normal  thoughts  about  a  program.  Some  are  more  difficult  to  state  because 
designers  do  not  normally  take  into  account  all  the  possible  values  that  a 
variable  can  take  on.  Finally,  some  are  very  difficult  to  state  because 
they  require  a  statement  of  the  assumptions  upon  v/hlch  a  design  is  based. 

Primarily  because  some  assertions  are  more  difficult  to  state  than 
others,  the  Software  Quality  Laboratory  is  able  to  accept  a  partially 
asserted  program  and  use  these  to  detect  some  errors.  This  is  similar  to 
the  early  detection  of  hardware  errors  where,  due  to  the  difficulty  of  a 
complete  check,  parity  checks  are  made  on  memories  assuming  only  a  single 
bit  per  word  could  be  in  error. 

2.3.1  Asserted/Actual  Use 

One  of  the  easiest  assertions  to  state  is  one  of  the  most  powerful 
in  checking  the  correct  usage  of  variables  between  modules.  A  common 
error  is  the  use  of  a  variable  as  an  input  to  a  routine  when  it  is  an 
output,  or  vice  versa.  In  languages  where  a  large  number  of  variables 
are  said  to  be  "known"  to  the  program,  as  in  FORTRAN  with  i ts  COMMON 
blocks  or  in  PASCAL  with  its  global  variables,  errors  in  the  misuse  of 
variables  are  costly  to  find. 

In  order  to  aid  in  checking  that  each  variable  is  used  correctly, 
the  INPUT, OUTPUT  assertions  were  designed  and  implemented  both  to  provide 
an  error  detection  capability  before  execution  of  the  program  and  a  trace 
of  the  input  and  output  variables  during  test  runs.  The  error  detection 
capability  is  further  discussed  in  Sec.  U  and  the  trace  capability  is 
discussed  in  Sec.  3.  Basically,  what  is  checked  is  how  the  assertion 
that  states  how  a  variable  is  to  be  used  in  a  given  module  matches  with 
its  actual  use.  For  example,  consider  a  routine  TIMES  that  multiplies 
A  and  3  together  and  stores  them  in  C: 
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PROCEDURE  times  (VAR  a,  b,  c  :  integer); 


SUBROUTINE  TIMES  (A,  B,  C) 
INTEGER  A,  B,  C 

COMMENT  ***  INPUT  ASSERTION  *** 

INPUT  (/lU'TEGER/A,  B) 
C  =  0 

WHILE  (B  .GT.  0) 

C  -  C  +  A 
B  =  B  -  1 
END  WHILE 

COMMENT  ***  OUTPUT  ASSERTION  *** 
OUTPUT  (/INTEGER/C) 
RETURN 

END 

IFTRAN  Input/Output  Error 


BEGIN 

(***  INPUT  ASSERTION  ***) 
INPUT  a,  b; 

L  0; 

WHILE  b  >  0  DO 

c  :=  c  +  a; 
b  :=  b  -  1 
END  WHILE; 

(***  OUTPUT  ASSERTION  ***) 
OUTPUT  c 

END; 


V-PASCAL  Input/Output  Error 


An  error  would  be  reported  since  the  value  of  B  is  changed.  Hence  B  is 
not  .just  an  input,  it  is  also  an  output. 

More  important  is  the  capability  for  checking  that  variables  are 
used  correctly  across  modules.  In  the  following  example,  the  variable 
ANS  is  asserted  to  be  used  both  as  an  INPUT  and  as  an  OUTPUT.  It  is 
Intended  that  the  CALL  will  compute  ANS  times  F  and  store  the  result 
in  ANS,  but  because  the  TIMES  module  expects  ANS  to  be  used  only  as  an 
INPUT  as  the  first  parameter,  and  only  as  an  OUTPUT  as  the  third  para¬ 
meter,  errors  would  be  reported.  In  this  example,  note  that  since  TIMES 
sets  the  OUTPUT  variable  C  to  zero,  ANS  would  also  be  set  to  zero  and 
the  result  would  be  zero.  Such  errors  can  be  extremely  difficult  to  find 
if  several  levels  of  a  subroutine  hierarchy  are  involved. 
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INTEGER  ANS,  F 


ans,  f  :  Integer; 


COMMENT  ***  INPUT  ASSERTION  *** 
INPUT  (/INTEGER /ANS,  F) 


(***  INPUT  ASSERTION  ***) 
INPUT  ans,  f; 


CALL  TIMES  (ANS,  F,  ANS) 


times  (ans,  f,  ans); 


COMMENT  ***  OUTPUT  ASSERTION  *** 
OUTPUT  (/INTEGER /ANS) 


(***  OUTPUT  ASSERTION  ***) 
OUTPUT  ans; 


IFTRAN  Input/O'jcput  V-PASCAL  Input/Output 

Multimodule  Error  Multimodule  Error 


2.3.2  Units  Consistency 

Another  simple-to-state  but  very  powerful  assertion  is  the  UNITS 
assertion  which  is  used  to  check  that  units  are  consistent  throughout  a 
program.  This  is  further  discussed  in  Sec.  4,  but  a  brief  example  is 
appropriate  here. 

The  units  check  is  one  that  everyone  trained  in  the  physical 
sciences  has  been  urged  to  apply.  Basically,  it  prevents  apples  being 
assigned  to  oranges,  miles  being  assigned  to  feet,  dollars  being  added 
to  pounds,  and  other  similar  but  troublesome  errors,  as  demonstrated 
here: 
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^IKKurMNI  I’AYKi'l  (ims.  K,M  I  ,  »'A^  .  TAX) 

Klj\l  MKS.  KAIf  .  .  IA\ 

mM-MiSI  ***  I'NIIS  AsSIRlM'N  *■** 

(MHS  •  HOI  KS,  RAI  I  •  DHl.l  AR<; /HOI  H .  PAN  •  tMHlAK'., 
*  TAX  -  IhH.I  AHS  /1m>I  ;  AH‘^  i 

PAN  •  HRS*KAn  -  lAX 
K»Tt(kN 

KX!! 


1  Kot  UH'Rl  p.ivrcl  <.hrM  ;  rp.il  i'NITS  ht)urH; 

(***  I’NITS  ASSIKFION  PAKI  OP  TYl'K  DTCLAKA  T  ION  ***) 
rnip  :  rr.il  I'MIS  tl'i  1  l.»rs/hour ; 

VAR  piiy  :  rf.il  UNIIS  dnlljir*;: 
t;iK  ;  n-al  INITS  tl.- 1 1  ,i rs/tl..  1  |.{rs); 

Rt.CIN 

p/iv  :  •  hrs*r,Ui-  -  tiix 

KND; 


IFTRAN  Units  Error  V-PASCAL  Units  Error 


Because  the  UNITS  of  TAX  do  not  match  the  UNITS  of  the  other  terms  in  the 
expression,  an  error  would  be  reported.  One  can  regard  the  UNITS  asser¬ 
tion  as  a  very  strong  type  declaration.  Designers  are  accustomed  to 
specifying  the  type  of  arithmetic  that  their  machine  is  using.  Many 
recognize  the  dangers  of  mixed  mode  arithmetic,  and  the  advantages  of 
checking  to  verify  that  only  one  kind  of  arithmetic  is  actually  used  in 
an  expression.  However,  here  the  dangers  of  allowing  a  variable  named 
MONEY  expressed  in  dollars  at  one  time  and  at  another  time  being  expressed 
in  cents  have  been  overlooked.  In  IFTRAN  a  sepaiate  UNITS  statement  is 
used  for  the  UNITS  assertion.  In  V-PASCAL,  the  UNITS  assertion  is  part 
of  the  type  declaration. 

All  the  errors  and  assertions  discussed  to  this  point  can  be  found 
once  syntax  analysis  by  a  compiler  has  been  completed,  and  before  the 
program  is  submitted  for  an  execution  test. 

2.3.3  Logical  Assertions 

There  are  additional  assertions  which  can  be  used  in  the  execution 
test  (see  the  EXECUTION  step  in  Fig.  2.1)  and  which  can  also  be  used  in  a 
correctness  proof. 
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The  easiest  to  use  of  the  additional  assertions  is  the  INITIAL 
assertion.  The  INITIAL  assertion,  which  is  more  fully  described  in 
Secs.  3  and  5,  is  meant  to  provide  a  means  for  explicitly  stating  the 
initial  conditions  on  variables.  This  is  most  often  a  limitation  on 
the  range  that  a  variable  can  take  on.  For  example,  the  TIMES  program 
presented  in  this  section  would  not  operate  correctly  unless  B  ^  0  . 

This  condition  can  be  stated  in  the  INITIAL  assertion  by  placing,  as 
the  first  executable  statement  in  the  program, 

INITIAL  (B  .GE.  0)  INITIAL  b  >=  0; 

IFTRAN  ’  V-PASCAL 

which  will  ensure  that  on  every  entry  to  the  routine,  the  second  argument 
is  not  less  than  zero. 

One  might  also  note  that  the  TIMES  program  would  not  work  correctly 
if  the  result  of  A*B  were  too  large  for  the  machine.  This  error,  known 
as  fixed-point  overflow,  is  not  detected  on  many  machines  and  as  a  result 
can  be  a  costly  error  to  locate.  One  way  to  state  an  initial  assertion 
to  prevent  undetected  overflow  in  the  TIMES  program  would  be  to  ensure 
that  the  sum  of  the  powers  of  each  of  the  input  values  is  less  than  the 
largest  number  that  can  be  represented  in  the  machine.  We  would  then 
represent  the  assertion  by 

IFTRAN 

INITIAL  (B  .GE.  0  .AND.  POWER(A)  +  POWER(B)  .LT.  MAXP) 

V-PASCAL 

INITIAL  b  >=  0  AND  power(a)  +  power (b)  <  maxp; 

For  example,  in  a  small  computer  with  only  16-bit  words,  MAXP  would  be 
15.  In  a  computer  with  60-blt  worda,  MAXP  would  be  59. 

POWER  is  a  function  that  returns  which  power  of  2  is  greater  than 
or  equal  to  the  input  value 

-POWER  ^  ^  -POWER-1 

2  >  A  >  2 
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Any  time  that  an  assertion  is  not  true,  an  exception  report  is 
printed  stating  which  assertion  in  which  module  is  in  error.  Provision 
has  also  been  made  for  allowing  a  block  of  code  to  be  invoked  in  case  an 
assertion  is  not  true.  The  block  of  code  can  be  used  for  example  to 
correct  the  condition  that  caused  the  exception  or  to  print  out  more 
pertinent  error  messages. 

By  placing  additional  conditions  on  input  variables,  more  checks 
can  be  made  that  prevent  errors.  VThen  there  is  no  condition  stated  on 
an  input  variable,  it  is  equivalent  to  stating  that  any  value  from  the 
smallest  possible  represented  by  the  machine  to  the  largest  possible 
will  not  cause  an  error.  Since  this  is  a  very  unlikely  situation, 
thought  should  be  given  to  Just  what  conditions  are  being  assumed  by  the 
designer.  For  example,  in  a  particular  payroll  program  it  might  be  known 
that  a  person  can  never  work  more  than  168  hours  between  checks,  that  the 
pay  rate  can  never  be  more  than  $25.00  per  hour,  and  that  the  tax  rate 
can  never  be  more  than  50%.  We  could  state  this  in  an  assertion  as 

IFTRAN 

INITIAL  (HOURS  .LE.  168  .AND.  RATE  .LE.  25.00  .AND.  TAX 
.LT.  0.50) 

V-PASCAL 

INITIAL  hours  <=  168  AND  rate  <=  25.00  AND  tax  <  0.50; 

if  the  input  variables  were  HOURS,  RATE,  and  TAX.  This  would  help  pre¬ 
vent  errors  such  as  might  result  from  reading  or  punching  a  time  card 
Incorrectly. 

Besides  stating  assertions  on  the  input  variables  with  an  INITIAL 
assertion,  it  is  also  possible  to  state  assertions  on  output  variables 
with  a  FINAL  assertion.  As  with  the  INITIAL  assertion,  the  FINAL 
assertion  can  also  be  used  to  check  on  ranges  of  output  variables  such 
as  in  a  payroll  program  to  check  that  an  employee  is  not  paid  too  much 
or  too  little, 
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IFTRAN 


FINAL  (PAY  .LT.  500.00  .AND.  PAY  .GT.  40.00) 

V-PASCAL 

FINAL  pay  <  500.00  AND  pay  >  40.00; 

or  in  a  flight  control  program  to  check  that  an  airplane  is  not  too  high 
or  too  low 

IFTRAN 

FINAL  (HEIGHT  .LT.  MAXALT  .AND.  HEIGHT  .GT.  MINALT) 

V-PASCAL 

FINAL  height  <  maxalt  AND  height  >  minalt; 

or  in  a  chemical  processing  program  to  check  that  the  calculated 
temperature  denotes  the  liquid  state 

IFTRAN 

FINAL  (TEMP  .LT.  BOIL  .AND.  TEMP  .GT.  FREEZ) 

V-PASCAL 

FINAL  temp  <  boil  AND  temp  >  freez; 

or  in  an  airline  reservation  system  to  denote  that  the  number  of  seats 
remaining  is  reasonal^le 

IFTRAN  I 

FINAL  (SEATS  .LT.  425  .AND.  SEATS  .GE.  0) 

V-PASCAL 

FINAL  seats  <  425  AND  seats  >  0; 

It  is  better  to  state  acceptable  ranges  of  output  variables  than 
not  to  state  anything  about  a  variable  so  that  obvious  problems  can  be 
detected.  However,  it  is  best  if  possible  to  state  the  results  of  the 
module  in  terms  of  the  input  variables  so  that  the  assertion  can  be 
used  in  a  formal  verification.  This  is  not  very  difficult  to  do  if, 
for  example,  a  series  approximation  is  being  used  and  the  error  term 
is  known  or  if  the  Inverse  function  is  known. 
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For  example,  if  the  module  computed  the  square  root  of  an  Input 
variable  x  and  the  result  was  in  y,  the  final  assertion  could  be: 

IFTRAN 

FINAL  (Y**2  .EQ.  X) 

V-PASCAL 

FINAL  y*y  =  x; 

which  uses  the  operation  of  raising  to  a  power  of  2  as  the  inverse 
operation  of  square  root. 

In  the  TIMES  module  given  previously  the  final  assertion  could  be 
IFTRAN 

FINAL  (C  .EQ.  A*B) 

V-PASCAL 

FINAL  c  =  a*b; 

A  check  on  the  calculation  of  the  altitude  of  a  plane  might  be 
IFTRAN 

FINAL  (ALT**2  +  GND**2  .EQ.  RANGE**2) 

V-PASCAL 

FINAL  alt*alt  +  gnd*gnd  =  range*i.’ange; 

The  object  of  a  FINAL  assertion  is  to  place  as  tight  a  condition 
on  an  output  variable  as  possible.  In  the  examples  shown,  an  equality 
relation  was  used.  This  is  the  strongest  relation  that  can  be  used. 
However,  in  other  cases  a  bound  is  expressed.  For  example,  it  might  be 
necessary  in  a  floating  point  machine  to  state  a  relative  bound  on  a 
result  such  as 

IFTRAN 

FINAL  (Y**2  -  X  .LT.  3.0E  -  10*X) 


V-PASCAL 

FINAL  y*y  -  x  <  3.0e  -  10*x 

where  3.0e  -  10*x  is  the  error  bound  of  the  algorithm. 

The  FINAL  assertion  is  meant  to  provide  a  facility  for  specifying 
a  program's  function.  When  it  thoroughly  specifies  all  the  outputs  of 
the  routine,  it  can  be  used  in  a  formal  program  verification  as  described 
in  Sec.  6.  When  it  partially  specifies  the  outputs,  it  can  be  used  during 
execution  test  as  described  in  Sec.  5  for  fault  detection  and  assertion 
refinement. 
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3  LANGUAGE  EXTENSIONS  AND  IMPROVEMENTS 

The  Statement  of  Work  requirement  to  produce  verifiable  software 
written  in  FORTRAN  or  PASCAL  has  been  met  by  GP.C,  in  part,  by  improving 
the  readability  of  the  code  and  by  adding  features  to  support  automated 
verification.  This  section  describes  a  number  of  changes  which  respond 
to  these  needs.  The  language  changes  fall  into  several  categories: 

•  Improved  control  structures,  which  are  easier  to  write  and 
which  result  in  more  readable  code 

•  Executable  assertion  statements  (ASSERT,  INITIAL,  FINAL), 
which  may  be  used  to  report  assertion  exceptions  during 
testing  and  can  also  be  used  by  a  program  verifier 

•  Data  access  statements  (INPUT,  OUTPUT),  which  qualify  or 
limit  the  access  rights  and  operations  on  data  by  explicitly 
specifying  the  input  and  output  variables 

•  Unit  qualifiers  for  variables,  which  declare  the  physical 
units  in  addition  to  any  type  declarations,  thereby  making 
units  consistency  checking  possible 

These  capabilities  are  Implemented  with  preprocessors  which  accept  as 
input  source  code  written  in  an  extended  language  (IFTRAN  or  V-PASCAL) 
and  generate  a  standard  language  (FORTRAN  or  PASCAL)  for  compilation. 
Figure  3.1  is  sample  IFTRAN  program  showing  the  assertions  and  some  con¬ 
trol  constructs.  A  portion  of  a  PASCAL  program  that  uses  some  of  the 
language  enhancements  is  shown  in  Fig.  3.2. 

3.1  IMPROVED  CONTROL  STRUCTURES 

3.1.1  IFTRAN  Control  Constructs 

Unlike  PASCAL  and  ALGOL-based  languages  (in  which  complex  state¬ 
ments  are  built  in  terms  of  decision  statements  and  BEGIN... END  clauses), 
IFTRAN  control  constructs  are  composed  of  readily  identifiable  and 
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Figure  3.1.  Example  Showing  Use  of  IFTRAN  Language  Extensions 


matching  control  statements.  IFTRAN  constructs  are  defined  by  pairs  of 
beginning  and  ending  IFTRAN  control  statements.  The  following  pairs 
are  legal: 

IF... END  IF 
WHILE... END  WHILE 
DO. . .END  DO 
REPEAT. . .UNTIL 
LOOP... END  LOOP 
FOR. ..END  FOR 
BLOCK... END  BLOCK 

Beginning  IFTRAN  control  statements  (IF,  WHILE,  DO,  REPEAT,  LOOP,  FOR, 
BLOCK)  cause  right  indentation  one  level  for  succedlng  statements. 
Ending  IFTRAN  control  statements  (END  IF,  END  WHILE,  END  DO,  UNTIL,  END 
LOOP,  END  FOR,  END  BLOCK)  immediately  cause  left  indentation  one  level. 
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IFTRAN  control  statements  which  must  match  are  connected  with  vertical 
dots  on  the  indented  IFTRAN  source  listing: 


CORRECTLY  NESTED  CONSTRUCTS 
IF  (  ) 

.  WHILE  (  ) 

.  .  DO  (  ) 

.  .  .  statement (s) 

.  .  END  DO 
.  END  WHILE 
END  IF 

This  enhances  the  visibility  of  program  structure,  as  well  as  providing 
a  visual  debugging  aid.  Indentation  level  must  be  zero  when  an  END 
statement  is  encountered. 

An  IFTRAN  control  statement  is  either  an  IFTRAN  keyword  or  an 
IFTRAN  keyword  followed  by  a  character  string  contained  within  balancing 
parentheses.  Proper  combinations  of  IFTRAN  control  statements  form 
IFTRAN  control  constructs. 

The  simplest  IFTRAN  control  statement  has  the  form 
IFTRAN-KEYWORD 

where  IFTRAN-KEYWORD  may  be  ELSE,  END  IF,  END  WHILE,  REPEAT,  END  DO, 

END  FOR,  LOOP,  EXIT,  END  LOOP,  END  BLOCK,  or  END.  Blanks  within  IFTRAN  . 
keywords  are  not  significant.  Each  ke5Word  must  be  a  separate  statement. 

The  second  form  of  an  IFTRAN  control  statement  is 
IFTRAN-KEYWORD  (CHARACTER-STRING) 

where  IFTRAN-KEYWORD  may  be  IF,  ORIF,  EXIT  IF,  WHILE,  UNTIL,  DO,  FOR, 
INVOKE,  or  BLOCK.  Keyword  conventions  are  the  same  as  for  the  simpler 
IFTRAN  control  statement  form.  For  a  statement  of  this  form  to  be  an 
IFTRAN  statement,  the  left  parenthesis  following  the  keyword  must  be 
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balanced  by  the  last  non-blank  character  of  the  statement  (which  must  be  ' 

a  right  parenthesis).  Parentheses  within  Hollerith  strings  are  not 

counted. 

The  form  of  CHARACTER- STRING  is  not  examined  by  the  IFTRAN  pre¬ 
processor  (except  for  balancing  parenthesis  and  restrictions  in  the  DO 
and  FOR  statements).  To  be  translated  into  compilable  FORTRAN,  CHARACTER¬ 
STRING  should  be  a  FORTRAN  logical  expression  for  keywords  IF,  ORIF,  WHILE, 

UNITE,  and  EXIT  IF.  If  the  embedded  language  is  not  FORTRAN,  this  is  not 
necessary.  For  example,  the  embedded  language  can  be  English  for 
purposes  of  program  design  documentation. 

IFTRAN  STATEMENTS 
IF (COMPUTATION  IS  COMPLETE) 

WHILE (FLIGHT  76  IS  IN  DULLES) 

IF... ORIF... ELSE... END  IF 

The  IF. . .ORIF. . .ELSE. . .END  IF  construct  provides  the  ability  to  ) 

select  at  most  one  (but  possibly  none)  among  several  alternate  groups  of 
statements  to  execute.  The  basic  form  of  this  construct  is  the  matching 
IF... END  IF  pair.  If  the  FORTRAN  EXPRESSION  is  true,  control  proceeds 
to  the  first  statement  within  the  construct;  otherwise  control  transfers 
to  the  END  IF  statement. 

Use  of  the  ORIF  and  ELSE  are  optional.  There  may  be  more  than  one 
ORIF  condition  stated;  they  will  be  tested  consecutively  and,  if  one  of  ^ 

the  conditions  is  true,  control  will  be  transfered  to  the  first  statement 
after  that  ORIF.  Otherwise,  control  proceeds  to  an  ELSE,  if  one  is  * 

present,  or  the  END  IF.  Figure  3.3a  shows  the  Statement  Syntax  and  3.3b 
is  a  Construct:  Flowchart. 
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Figure  3.3a.  Statement  Syntax 


Figure  3.3b.  Construct  Flowchart 


Figure  3.3.  IF. . .ORIF. . .ELSE. .  .END  IF  Construct 


WHILE. . .END  WHILE 

The  WHILE... END  WHILE  construct  indicates  a  repetitive  operation 
which  is  to  be  performed  zero  or  more  times.  It  is  essentially  a 
single-exit  loop  which  exits  at  the  top  of  the  loop.  Figure  3.4 
illustrates  the  form  and  meaning  of  this  construct.  It  is  Important 
'to  note  that  no  initialization  or  incrementing  operations  are  caused 
by  the  WHILE... END  WHILE  construct.  Initialization  must  be  explicitly 
performed  before  entering  the  loop,  and  the  iteration  variables  must  be 
explicitly  modified  on  each  pass  through  the  loop. 

DO... END  DO 

The  DO... END  DO  construct  Indlciates  a  repetitive  operation  that 
is  to  be  performed  one  or  more  times.  It  is  a  single-exit  loop  with 
the  exit  at  the  bottom.  Figure  3.5  illustrates  this  construct.  It  has 
the  same  meaning  as  the  FORTRAN  DO-LOOP;  however,  no  label  is  necessary, 
and  (CHARACTER-STRING)  must  be  of  the  form  (INDEX=  INITIAL, FINAL,  INCR) 
where  each  of  these  variables  is  a  simple  integer  variable  or  constant 
(except  for  INDEX,  which  must  be  variable).  If  INCR  is  not  present,  it 
is  assumed  to  be  1.  The  value  of  INDEX  is  not  defined  after  DO... END  DO 
termination.  The  Implied  Initialization  and  incrementing  operations  are 
indicated  in  Fig.  3.5b. 

REPEAT. . .UNTIL 

The  REPEAT. .  .UNTIL  construct  is  like  a  DO... END  DO  in  that  it  is 
performed  at  least  once  and  has  a  single  exit  at  the  bottom  of  the  loop, 
and  like  a  WHILE... END  WHILE  in  that  no  initialization  or  incrementing 
operations  are  caused  by  this  construct.  Initialization  must  be  performed 
before  entering  the  loop,  and  iteration  variables  must  be  modified  on  each 
pass  through  the  loop.  Figure  3.6  illustrates  this  construct. 
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c)  FORTRAN  Example 

Figure  3.4.  WHILE... END  WHILE  Construct 
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c)  FORTRAN  Example 


Figure  3.5.  DO... END  DO  Construct 
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c)  FORTRAN  Example 

Figure  3.6.  REPEAT. . .UNTIL  Construct 
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LOOP. . .EXIT. . .EXIT  IF... END  LOOP 

The  basic  LOOP... END  LOOP  construct  Is  a  loop  structure  with  no 
exit  (an  infinite  loop)  and  no  Implied  initialization  or  iteration  con¬ 
ditions.  At  least  one  EXIT  or  EXIT  IF  statement  should  be  used  in  each 
LOOP,  END  LOOP  construct.  An  EXIT  or  EXIT  IF  statement  is  associated 
with  the  first  END  LOOP  statement  following  it.  As  shown  in  Figs.  3.7 
and  3.8,  EXIT  and  EXIT  IF  statements  cause  control  to  transfer  to  the 
first  statement  after  the  END  LOOP,  and  are  indented  to  the  level  of 
the  corresponding  LOOP... END  LOOP  pair.  This  construct  is  most  useful 
for  loops  which  naturally  exit  in  the  middle  or  ituiy  have  more  than  one 
reason  for  exiting. 

FOR... END  FOR 

The  FOR... END  FOR  construct  allows  a  variety  of  loops  to  be  built 
from  an  Initialization  clause,  modification  clauses,  and  condition  clauses. 
The  Initialization  clause  is  required  to  provide  an  initial  value  for  the 
FOR  index  variable.  The  index  variable  will  have  the  last  value  assigned 
to  it  when  the  FOR... END  FOR  construct  terminates.  Optional  modification 
clauses  provide  for  changing  the  FOR  index  variable  other  than  incrementing 
by  one  (which  is  the  default  value).  Escape  tests  at  the  top  or  bottom 
of  the  FOR  loop  are  constructed  with  optional  condition  claiises. 

A  FOR... END  FOR  construct  with  only  an  initialization  clause  has 
the  form: 

FOR  (INDEX  »  INITIAL) 

.  BODY  OF  FOR... END  FOR 

END  FOR 
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c)  FORTRAN  Example 


3.8.  LOOP ... EXIT ... END  LOOP  Construct 
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INDEX  is  any  variable  which  is  legal  on  the  left-hand  side  of  a  FORTRAN 
assignment  statement.  The  FORTRAN  expression  "INITIAL"  defines  the 
value  which  is  assigned  to  the  index  variable  when  the  FOR... END  FOR 
construct  is  entered.  The  index  variable  is  incremented  by  one  after 
the  body  of  the  FOR... END  FOR  is  executed.  This  form  will  cause  an 
infinite  loop.  It  is  shown  separately  to  allow  a  clearer  explanation  of 
the  initialization  clause  alone. 

One  of  the  following  modification  clauses  can  be  used  to  alter  the 
default  Incrementing  of  the  index  variable.  The  "BY"  clause  allows 
positive  or  negative  increments  to  be  specified.  A  FOR. ..END  FOR  con¬ 
struct  with  a  "BY"  clause  has  the  form: 

FOR  (INDEX  -  INITIAL  BY  INCR) 

« 

.  BODY  OF  FOR... END  FOR 

END  FOR 

A  legal  FORTRAN  arithmetic  expression  to  be  used  for  incrementing  is 
specified  with  "INCR".  This  form  will  also  not  terminate.  The  "NEXT" 
clause  can  be  used  to  specify  new  values  of  the  index  variable.  A 
^OR...END  FOR  construct  with  a  "NEXT"  clause  has  the  form: 

FOR  (INDEX  -  INITIAL  NEXT  EXPR) 

■  Vx 

.  BODY  OF  FOR... END  FOR 

END  FOR 

"EXPR"  is  a  valid  FORTRAN  arithmetic  expression  whjcn  is  used  to  compute 
the  next  value  of  the  index  variable.  This  form  will  not  terminate. 


Several  of  the  following  condition  clauses  can  be  used  to  specify 
FOR  loop  termination  conditions.  The  "TO"  clause  is  useful  to  specify 
a  bound  on  the  index  variable.  This  construct  has  the  form; 

FOR  (INDEX  -  INITIAL  TO  FINAL) 

.  BODY  OF  FOR... END  FOR 

END  FOR 

A  "TO"  clause  and  a  "BY"  clause  may  be  used  in  the  same  FOR  loop.  The 
"TO"  clause  alone  will  cause  the  index  variable  to  be  Incremented  by 
one  each  time  through  the  loop.  When  the  BY  clause  is  used  the  incre¬ 
ment  is  specified  in  the  clause.  A  "NEXT"  clause  cannot  be  used  with  a 
"TO"  clause.  If  the  "INCR"  specified  in  the  "BY"  clause  is  negative, 
the  appropriate  termination  test  is  performed. 

The  "WHILE"  clause  allows  an  escape  condition  to  be  inserted  at 
the  top  of  the  FOR  loop.  This  construct  has  the  form; 

FOR  (INDEX  -  INITIAL  WHILE  COND) 

.  BODY  OF  FOR.  ..END  FOR 

END  FOR 

"COND"  is  a  legal  FORTRAN  logical  expression.  The  index  variable  wixl 
be  incremented  by  one  after  starting  at  the  INITIAL  value.  The  escape 
test  is  at  the  top  of  the  loop. 

The  "UNTIL"  clause  allows  an  escape  condition  to  be  inserted  at 
the  bottom  of  the  FOR  loop.  This  construct  has  the  form: 

FOR  (INDEX  -  INITIAL  UNTIL  COND) 

.  BODY  OF  FOR... END  FOR 

END  FOR 


As  in  the  "WHILE"  clause,  COND  Is  a  legal  FORTRAN  logical  expression. 

A  "WHILE"  or  "UNTIL"  clause  can  be  used  with  any  of  the  other  FOR 
clauses. 

The  For  construct  and  related  clauses  can  be  used  to  state  a  wide 
variety  of  loops.  Restrictions  in  using  the  FOR... END  construct  are: 

1.  An  initialization  clause  must  be  used,  and  it  must  be  the 
the  first  clause. 

2.  The  "NEXT"  clause  cannot  be  used  with  either  "TO"  or  "BY" 
clauses. 

3.  Each  clause  keyword  (BY,  NEXT,  TO,  WHILE,  UNTIL)  must  be 
preceded  and  followed  by  a  blank. 

One  example  of  the  FOR.  ..END  FOR  construct  is  shown  in  Fig.  3.9a, 
b,  and  c. 

BLOCK... END  BLOCK  and  INVOKE 

The  BLOCK. . . END  BLOCK  construct  provides  a  form  of  Internal  sub¬ 
routine  capability  in  IFTRAN  source  programs.  This  construct  is  an 
internal  procedure  which  has  access  to  all  variables  in  the  routine 
which  contains  it.  A  BLOCK. ..END  BLOCK  is  executed  only  if  it  is 
referred  to  with  an  INVOKE  statement  which  specifies  its  name.  The 
name  of  the  BLOCK  below  is  CHARACTER-STRING: 

BLOCK(CHARACTER- STRING) . 

All  characters  in  CHARACTER- STRING  are  significant  after  the  first  non¬ 
blank  and  before  the  last  non-blank;  (this  allows  names  of  more  than 
six  characters  so  that  the  name  can  have  mnemonic  significance). 

Figure  3.10  Illustrates  this  construct.  As  the  flowchart  for  this 
construct  Indicates,  it  is  a  single-entry  (the  BLOCK  statement),  single- 
exit  (the  END  BLOCK  statement)  section  of  code.  An  INVOKE  statement 
causes  control  to  transfer  to  the  named  BLOCK  statement,  and  the 
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matching  END  BLOCK  statement  causes  control  to  transfer  back  to  the 
statement  after  the  INVOKE.  More  than  one  INVOKE  for  a  given  BLOCK. . . 

END  BLOCK  construct  is  allowed.  Though  BLOCK... END  BLOCK  constructs 
can  be  nested,  no  recursion  is  allowed  in  the  invoking  of  BLOCKS 
(i.e.,  a  BLOCK  cannot  directly  or  indirectly  Invoke  itself).  Also, 
the  name  of  a  BLOCK  is  known  throughout  the  entire  routine  in  which  it 
is  contained.  BLOCKS  cannot  be  invoked  from  an  external  routine,  nor 
can  they  be  passed  as  a  parameter  to  another  routine. 

3.1.2  PASCAL  Control  Constructs 

The  PASCAL  language  provides  a  basic  framework  for  programming 
structured  software.  Such  features  as  nested  procedure  declarations, 
nested  control  structures,  data  typing  and  data  structure  hierarchy 

i 

with  controlled  access  by  scope  are  Important  when  writing  structured 
code. 

In  standard  PASCAL,  the  IF  statement,  CASE  statement,  WHILE 
statement,  FOR  statement,  and  WITH  statement  are  all  assumed  to  contain 
a  single  statement.  In  order  to  allow  the  inclusion  of  more  than  one 
statement  in  one  of  these  statements,  it  is  necessary  to  surround  the 
statements  with  the  words  BEGIN  and  END.  The  net  result  is  that  strings 
of  ENDS  can  appear  in  a  program  which,  on  occasion,  are  difficult  to 
pair  with  their  respective  BEGINS.  One  solution  has  been  for  a  programmer 
to  indent  the  statements  that  belong  together.  Another  solution  is  to 
improve  the  syntax  so  that  automatic  indenting  is  possible  with  a  single¬ 
pass  preprocessor.  This  relieves  the  programmer  from  counting  spaces  to 
achieve  readability  while  still  providing  an  Indented  listing.  It  also 
eliminates  the  need  for  BEGINS  within  control  structures  and  assigns 
more  meaning  to  the  ENDs.  This  is  accomplished  by  using  unique  keywords 
to  terminate  each  type  of  statement  or  to  separate  parts  of  the  statement. 


Thus,  where  original  PASCAL  has 
IF  year  >  =  500  THEN 

BEGIN  write  ('d');  year  :=  year  -  500  END; 

the  improved  syntax  lists  a  statement  entered  as: 

IF  year  >  =  500  THEN  write  ('d');  year  :=  year  -  500  END  IF; 

with  the  indented  listing: 

IF  year  >  =  500  THEN 
write  Cd*); 
year  :=  year  -  500 
END  IF; 

In  a  similar  manner,  where  the  original  PASCAL  has: 

WHILE  power  >  0  DO 

BEGIN  {ans*temp**power  *  base**exponent, power  >0) 

WHILE  NOT  odd  (power)  DO 

BEGIN  power  :*  power  DIV  2;  temp  :=  sqr(temp) 
END; 

power  :«  power  -  1;  ans  :*  temp*ans 
END; 

the  Improved  syntax  would  list  a  statement  entered  as: 

WHILE  power  >  0  DO 

{ans*teinp**power  *  base  **exponent,  power  >0} 

WHILE  NOT  odd  (power)  DO 

power  :•■  power  DIV  2;  temp  :*  sqr(temp) 

END  WHILE; 

power  :=  power  -  1;  ans  :»  temp*ans 
END  WHILE; 

with  the  indented  listing: 
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WHILE  power  >  0  DO 

tan9*temp**power  =  base  **exponent .power  >  0} 
WHILE  NOT  odd  (power)  DO 

power  :=  power  DIV  2; 
temp  sqrCtemp) 

END  WHILE; 
power  ;=  power  -  1; 
ans  :=  temp*ans 
END  WHILE; 


Where  the  original  PASCAL  has  a  statement  of  the  form: 

FOR  i  :=  0  TO  lim  DO 

BEGIN  X  d*i;  y  :=  exp(-x)*sin(c*x) ; 
n  :*  round (s*y)  +  h; 

REPEAT  write  ('  ');  n  n  -  1 
UNTIL  n  =  0; 
writeln  ('*') 

END;  , 

The  changed  syntax  provides  an  indented  listing  of  the  form 

FOR  i  :=  0  TO  lim  DO 
X  :=  d*i; 

y  :*  exp(-x)*sin(c*x) ; 
n  round  (8*y)  +  h; 

REPEAT 

write  (’  •); 
n  ;•=  n  -  1 
UNTIL  n  -  0; 
writeln  (’*') 

END  FOR; 
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Where  the  original  PASCAL  has  a  statement: 

WITH  vaccine  [child3]  DO 

BEGIN  month  :=  april;  day  :=  23;  year  :=  1973 
END; 

the  Indented  PASCAL  listing  reads: 

WITH  vaccine  [child 3]  DO 
month  :=  april; 
day  :=  23; 
year  :=  1973 
END  WITH; 

The  CASE  statement  in  PASCAL  permits  the  selection  oi  alternative 
actions  based  on  the  evaluation  of  a  single  expression.  Where  the 
original  PASCAL  has; 

CASE  1  OF 

0:  aide  :=  0. ; 

1:  side  :■  sln(angle); 

2:  side  :*  cos (angle); 

3:  side  exp (angle); 

4:  side  ;=  In(angie) 

END 

The  Improved  syntax  looks  like  this  statement: 

CASE  i 

OF  0:  side  =  0. 

OF  1:  side  :«  sin (angle) 

OF  2:  side  :®  cos (angle) 

OF  3:  side  :■  exp (angle) 

OF  4:  side  :■  In(angle) 

END  CASE; 
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and  the  Indented  listing: 

CASE  i 

OF  0:  side  =  0. 

OF  1:  side  :=  sin(angle) 

OF  2:  side  :=  cos (angle) 

OF  3:  side  :=  exp (angle) 

OF  4:  side  :=  In(angle) 

END  CASE; 

Note  that  the  separator  semicolon  (;)  has  been  replaced  by  the  keyword 
0F« 


Other  programming  languges  (e.g.,  JOVIAL  and  IFTRAN)  offer  a 
language  construct  for  alternative  statement  selection  that  is  more 
powerful  than  the  PASCAL  CASE  statement,  namely  the  IF, . .ORIF. . .ELSE 
construct.  The  IF,  each  ORIF,  and  a  terminating  ELSE  constitute  a 
sequence  of  alternatives.  Each  has  an  associated  expression,  and  the 
first  expression  in  the  sequence  which  evaluates  as  true  determines  the 
alternative  selected.  Where  in  the  original  PASCAL  a  succession  of 
nested  IF  statements  is  required  to  state  more  complex  alternatives: 

IF  distance  >  0.  THEN  answer  :=  distance  +  minimum 

ELSE  IF  distance  *  0.  THEN  answer  :=  abs (minimum) 

ELSE  IF  distance  <  minimum  THEN  answer  :=  minimum 
ELSE  answer  :=  special; 

y' 

the  improved  syntax  reads: 

IF  distance  >  0.  THEN  answer  ;■  distance  +  minimum 
ORIF  distance  “  0.  THEN  answer  :=  abs  (minimum) 

ORIF  distance  <  minimum  THEN  answer  minimum 

ELSE  answer  :=  special 

ENDIF; 
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with  the  indented  listing: 


IF  distance  >  0.  THEN 

answer  :=  distance  +  minimum 
ORIF  distance  =  0.  THEN 

answer  :=  abs (minimum) 

ORIF  distance  <  minimum  THEN 
answer  :=  minimum 

ELSE 

answer  :=  special 

ENDIF; 


The  advantages  of  these  changes  are: 


1.  A  readable  indented  listing  is  provided  whether  the  programmer 
indented  the  source  code  or  not. 

2.  The  END  statements  do  not  require  comments  to  tag  them  to 
keywords  such  as  END{with}. 

3.  Numerous  BEGINS  are  eliminated. 


4.  The  flavor  of  PASCAL  is  retained. 

5.  Standard  PASCAL  can  be  generated  to  retain  compatibility. 

The  syntax  for  these  statements  is  defined  in  Fig.  3.11;  the  syntax 

* 

diagrams  are  shown  in  Fig.  3.12.  Figure  3.13  shows  the  indented  listing 
for  a  PASCAL  program  which  utilizes  most  of  these  control  structures. 


The  Syntax  diagrams  shown  in  Figs.  3.12,  3.15,  3.17,  and  3.19  depict 
changes  to  those  in  Ref.  12. 


<if  statement>:; 


* 

If  <expres8ion>  then  <8tatement  li8t>  <alternative>  end  If 
<alternatlve> {orlf  <expre8slon>  then  <8tatement  ll8t>}| 

{orlf  <expreaslon>  then  <8tatement  ll8t>}  else  <8tatement  ll8t> 

*  <ca8e  statement> : 

case  <expresslon>  of  <case  list  element> 

{or  <case  list  elenient>}  end  case 

*  <case  list  element>:  :=-<case  label  list> :  <statement  llst>| 

<einpty> 

*  <whlle  statement> ;  !■ 

while  <expres8ion>  ^  <statement  llst>  end  while 

*  <for  statement>: :■ 

for  <control  variable>:«<for  li8t>  do 
<statement  li8t>  end  for 

*  <with  statement>: :■ 

with  <record  variable  li8t>  ^ 

<statement  ll8t>  end  with 

+  <8tatement  list>; :*<statement>{ ;<statement>} 

* 

Denotes  change  to  existing  BNF. 

^Denotes  addition  to  existing  BNF. 


Figure  3.11.  PASCAL  Statements  for  Control  Structures 


Figure  3.12.  Syntax  Diagrams  for  Control  Structures 
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«3* 


Figure  3.13.  Example  Showing  Improved  PASCAL  Control  Structures 


3.2  EXECUTABLE  ASSERTIONS 

The  addition  of  assertions  to  a  language  provides  the  designer 
and  programmer  with  a  tool  for  stating  specifications  that  can  be  used 
as  a  basis  for  static  consistency  checking  and  program  • erification  as 
well  as  for  execution  tests.  This  capability  has  been  added  to  FORTRAN 
and  PASCAL  without  disrupting  the  Integrity  of  the  standard  langusi^es. 

The  existing  definition  of  expressions  was  retained,  and  the  ability 
to  state  quantified  logical  expressions  was  added. 

Three  keywords:  INITIAL,  ASSERT,  and  FINAL  were  added  to  the 
language  to  allow  the  expression  of  assertions.  As  the  names  imply, 
INITIAL  is  used  for  an  assertion  that  is  initially  true  on  entry  to  a 
program  or  procedure;  FINAL  is  used  for  a  final  assertion  that  is  true 
on  exit  from  a  program  jr  procedure;  and  ASSERT  is  used  anywhere  else. 

The  syntax  of  the  INITIAL/ASSERT/FINAL  assertions  is: 

FORTRAN  PASCAL 

KEYWORD  (assertion  expression)  KEYWORD  assertion  expression 

where  KEYWORD  is  INITIAL,  ASSERT,  or  FINAL  and  is  followed  by  any 
expression  that  evaluates  to  true  or  false.  Examples  are 

FORTRAN 

ASSERT  (LINEND  .GT.  ZERO) 

FINAL  (VOLUME  .  EQ .  HEIGHT* AREA) 

INITIAL  (COLOR  .EQ.  RED  .AND.  SIZE  .EQ.  10) 

PASCAL 

ASSERT  linend  >  zero; 

FINAL  volume  -  height*area; 

INITIAL  (color  «  red)  AND  (size  -  10) ; 


One  logical  operator  was  added  to  the  expression  used  in 
assertion  statements.  This  is  the  implication  operator  which  is 
represented  by  .IMP.  in  FORTRAN  and  by  the  pair  of  symbols  =>  in 
PASCAL.  Thus  it  is  possible  to  state 


FORTRAN 


PASCAL 


ASSERT  (P  .IMP.  Q)  ASSERT  p  =>  q; 

ASSERT  (A  .AND.  B  .IMP.  Q)  ASSERT  a  AND  b  *>  q; 

The  implication  operator  has  the  lowest  precedence  of  all  operators 
which  means  it  is  the  last  operator  to  be  evaluated. 

Quantified  expressions  are  defined  in  terms  of  the  keywords 
SOME  which  stands  for  3  and  ALL  which  stands  for  V  .  A  range  of 
values  is  stated  for  the  quantified  variable  in  a  similar  manner  to 
PASCAL  FOR  statements.  Examples  of  assertions  which  contain  quantified 
expressions  are: 


FORTRAN 


ASSERT  (.ALL.  I  IN  (FIRST,  LAST)  (ARRAY(I) 

.LT.  ARRAY  (I  -  1))) 

INITIAL  (.SOME.  J  IN  (1,  K)  (ARRAY (J) 

.EQ.  ANSWER)) 

PASCAL 

ASSERT  ALL  (i  IN  1  TO  n  IS 
a[l]  <  aii  +  11) 

INITIAL  SOME  (j  IN  1  TO  k  IS 
x[j]  =  answer) 

FINAL  ALL  (m  in  1000  DOWN  TO  1  IS 
y[m]  >-  x[n]) 

With  these  changes,  the  full  range  of  expressions  in  the  first- 
order  logic  may  be  stated.  However,  there  Is  one  more  type  of 
expression  that  is  useful  In  assertion  statements.  This  is  the 


definition  of  an  assertion  that  can  be  used  as  a  function.  For 
example,  to  assert  that  an  array  subtotal  has  been  zeroed  requires 
the  statement 

ASSERT  ALL  (i  IN  1  TO  length  IS 
subtotal[ I]  =  0) ; 

However,  if  this  type  of  assertion  is  common,  a  function  named  zeroed 
can  be  defined  so  that  we  can  state 

ASSERT  zeroed  (subtotal) ; 

v'hlch  requires  fewer  symbols  and  is  more  mnemonic.  The  declaration 
of  this  function  is  a  Boolean  type  PASCAL  function  whose  body  contains 
only  assertion  statements. 

PROCEDURE  zeroed  (a;  ARRAY  [1.. length]  OF  integer):  boolean; 
VAR  i:  integer; 

BEGIN 

ASSERT  ALL  (i  IN  1  TO  length  IS 

atil  -  0) 

END;  {zeroed} 

Upon  exit  from  the  procedure,  the  value  of  the  function  is  set  to  the 
conjunction  of  all  assertions. 

The  dorresponding  assertion  form  which  would  be  recognized  by  the 
IFTRAN  preprocessor  is 

ASSERT  (ZEROED  ( SBTOTL, LENGTH) ) 

The  code  for  the  function  would  be 

LOGICAL  FUNCTION  ZEROED  (SBTOTL, LENGTH) 

CMODN  ZEROED 

LOGICAL  ASSERT 

ASSERT  (.ALL.  I  IN  (1,  LENGTH)  (A(I)  .EQ.  0)) 

ZEROED  -  ASSERT 
RETURN 


The  assertion  statement  may  include  a  FAIL  clause.  The  FAIL  con¬ 
struct  is  a  vehicle  for  defining  an  exception  action  which  is  executed 
whenever  the  assertion  expression  evaluates  to  false.  In  an  IFTRAN 
program,  this  is  accomplished  with  a  FAIL  statement  which  invokes  an 
error-processing  routine  specified  by  the  user  and  contained  within  a 
BLOCK... END  BLOCK  construct.  Following  execution  of  the  BLOCK  procedure, 
control  is  transferred  back  to  the  statement  following  the  FAIL.  The 
syntax  of  the  FAIL  construct  is 

KEYWORD  (assertion  expression) 

FAIL  (name  of  BLOCK) 

• 

BLOCK  (name  of  BLOCK) 

END  BLOCK 

where  KEYWORD  is  INITIAL,  ASSERT,  or  FINAL.  An  example  is 

INITIAL  (  INDEX  .GT.  0  ) 

FAIL  (  PRINT  ERROR  CAUSE  ) 

• 

BLOCK  (  PRINT  ERROR  CAUSE  ) 

WRITE  (  L0UT,1) 

1  FORMAT  (  AlHOINPUT  PARAMETER  HAD  NO  MEANINGFUL  VALUE  ) 

END  BLOCK 

In  PASCAL,  a  sequence  of  statements  for  the  exception  action  starts 
with  the  keyword  FAIL  and  terminates  with  an  END  FAIL.  The  exception 
action  can  be  used  to  recover  from  erroneous  data  as  in  the  example: 

ASSERT  ALL  (i  IN  1  TO  20  IS  z  >  a[l]) 

FAIL  recover (z)  END  FAIL; 


3.2.1  FORTRAN 

INITIAL,  FINAL,  and  ASSERT  statements  are  normally  changed  to 
FORTRAN  comments  by  the  IFTRAN  preprocessor,  but  may  optionally  be 
changed  to  execute  FORTRAN  statements  which  provide  exception  reports 
whenever  the  assertion  Is  not  true  during  execution.  The  translation 
templates  are  presented  In  Appendix  C. 

Assertions  for  ASSERT  may  be  placed  anjrwhere  a  statement  may  be 
used.  The  INITIAL  and  FINAL  assertions  are  placed,  respectively. 
Immediately  before  and  after  the  executable  code.  It  Is  also  possible 
to  Include  any  or  all  of  these  assertions  within  a  BLOCK.. END  BLOCK 
construct;  the  same  rules  for  placement  apply. 

3.2.2  PASCAL 

The  PASCAL  assertion  for  INITIAL  Is  placed  Immediately  after  the 

BEGIN  which  starts  the  program  or  procedure  statements  (or  after  a 

* 

label  referenced  by  non-local  GOTO  statement  ) ,  and  the  assertion  for 
FINAL  Is  placed  Immediately  before  the  END  which  terminates  the  state¬ 
ment  part  of  a  program  or  procedure  (or  before  a  GOTO  which  transfers 
control  to  a  non-local  label  ).  Assertions  for  ASSERT  may  be  placed 
anywhere  a  statement  may  be  used.  The  syntax  for  executable  assertions 
Is  shown  In  Fig.  3.14  and  the  syntax  diagrams  are  In  Fig.  3.15.  The 
translation  templates  are  In  Appendix  B. 

3.3  DATA  ACCESS  STATEMENTS 

In  standard  PASCAL  and  FORTRAN,  a  program  module  has  access  not 
only  to  locally  declared  variables  but  also  to  variables  which  are 
declared  outside  the  scope  of  the  module.  Access  to  global  variables 
occurs  In  one  of  two  ways:  by  explicit  declaration  (l.e.,  those  appearing 
as  formal  parameters  or.  In  FORTRAN,  as  common  variables)  and,  in 

•k 

This  construct  violates  the  single  entry  restriction  for  a  module. 

** 

This  construct  violates  the  single  exit  restriction  for  a  module. 


54 


*  <unlabcl]cd  st.'iteiiient>:  :  = 

<slmplc  statement>  I  <structurctl  statenient>| 

<assertlon> 

+  <assertlon> : : ”  <lnitlal  asscrtion> | <assertlon  statement> | <f Inal  assertlon> 

+  <lnltial  asscrtlon> :  :  = 

Initial  •'assertion  cxpresslon>| 

Initial  <assertion  expression>  fail  <statement  llst>  end  fail 

<final  asser t  ion>  :  :  = 

final  <assertlon  expresslon> 

final  <assertion  expression>  fail  <statenent  list>  end  fall 

+  <assertlon  statement> : 

assert  <assertlon  exprosslon> ; j 

assert  •'assertion  expression>  fail  <statement  list>  end  fall 

+  <assertion  oxptession> : 

<quantified  expresslon> | <quantif led  expresslon> 

<quantlfied  exprcssion> 

+  <quantificd  oxpression> : 

all  <quantifier  tail>|  some  <quantifier  tail>| 

<exprossion> 

<quantlfler  tail>:;» 

(<control  variablo  Jji  <quantificr  list>  ^ 

<assertion  exprcssion>) 

+  <qu3ntifier  llst>::= 

<inltlal  value>  ^  <finnl  valuc>I 
<initlal  '<^alue>  down  to  <flnal  value> 

+  <initial  value>::=  <cxpresslon> 

<final  valu('>::=  <expresslon> 

A 

Dotiotes  ctianp.e  to  oxisting  BNI’ 

Denotes  addition  to  cxistin"  RNF 


Figure  3.14.  PASCAL  Statements  for  Assertions 


standard  PASCAL,  by  implicit  scope  rules  (i.e.,  all  variables  declared 
in  the  set  of  other  modules  which  contain  the  particular  module). 

INPUT  and  OUTPUT  assertions  specify  the  data  access  rights  to 
global  variables  and  are  used  in  static  consistency  checking  as  well  as 
dynamic  testing.  The  INPUT  statement  lists  those  variables  which  are 
input  (i.e.,  set  prior  to  entry)  to  the  module.  The  OUTPUT  statement 
lists  those -'/arlables  which  are  output  (e.g.,  assigned  or  read  from 
auxiliary  storage)  by  the  module.  This  restricts  the  global  variables 
which  may  be  ”.sed  or  set  by  the  particular  module. 

3.3.1  FORTRAN 

INPUT  and  OUTPUT  statements  are  normally  changed  to  FORTRAN  comments 
by  the  IFTRAN  preprocessor,  but  may  optionally  be  changed  to  executable 
FORTRAN  statements  which  cause  the  values  of  program  variables  to  be 
printed.  If  the  source  language  embedded  in  the  IFTRAN  program  is 
FORTRAN,  and  dynamic  tracing  of  input  or  output  variables  will  be  performed, 
a  specific  syntax  for  INPUT  and  OUTPUT  statements  is  required.  In  order 
to  print  with  a  correct  format,  the  INPUT  and  OUTPUT  statements  must 
pto’'ide  type  specifications.  Any  variables  whose  type  is  not  specified 
will  not  be  printed.  The  syntax  to  provide  type  information  is 

INPUT  (VARIABLE-LISTl) 
or 

OUTPUT  (VARIAliLE-LIST2) 

where  each  VARIABLE-LIST  is  /TYPE/VARIABLEl, /TYPE/VAR1ABLE2 ,  ...  and 
TYPE  is  one  of  REAL,  INTEGER,  HOLLERITH,  LOGICAL,  or  none.  Each 
VARIABLE  may  be  a  non-subscripted  variable  name,  array  name.  Individual 
element  of  an  array,  or  array  subrange.  A(I*1,  N)  specifies  a  subrange 
where  A  is  an  array  of  N  words  or  more.  I  is  a  variable  whose 
value  will  be  undefined  after  the  INPUT  or  OUTPUT  statement  is  executed. 
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Type  specifications  preceding  eacr.  v^ARIABLE  are  optional.  A  type 
specification  remains  in  effect  until  it  is  changed.  Only  variables 
with  REAL,  INTEGER,  HOLLERITH,  or  LOGICAL  type  specifications  will  be 
printed.  The  VARIABLE-LIST 

INDEX, /REAL/RANGE, DIST,/INTEGER/L(I  =  M,N) 

will  not  print  a  value  for  INDEX,  but  will  print  the  values  for  RANGE 
and  DIST  with  an  E  or  F  format  and  the  Mth  to  Nth  values  of 
array  L  with  an  integer  format.  The  variables  of  VARIABLE-LISTl  and 
VARIABLE-LIST2  need  not  be  distinct;  that  is,  a  variable  may  be  used  as 
both  input  and  output.  Figure  3.1  provides  a  specific  example  of  INPUT 
and  OUTPUT  statements. 

The  INPUT  statement  should  Immediately  precede  the  first  executable 
statement  of  a  program  or  block.  The  OUTPUT  statement  should  precede  the 
RETURN  or  STOP  statement  at  the  end  of  the  program  or  an  imbedded  RETURN 
or  STOP  which  la  before  the  end  of  the  program.  If  used  within  a  BLOCK, 
it  is  placed  after  all  executable  code  but  before  the  END  BLOCK. 

3.3.2  PASCAL 

The  INPUT  statement  is  positioned  after  tl. ;  first  BEGIN  in  the 
body  of  the  module.  Labels  referenced  by  non-local  GOTO  statements 
should  be  followed  by  an  INPUT  statement.  The  OUTPUT  statement  is 
positioned  prior  to  the  last  END  in  the  module  body.  GOTO  statements 
which  reference  non-local  statement  labels  should  be  immediately  preceded 
by  an  OUTPUT  statement.  The  syntax  of  INPUT  and  OUTPUT  statements  is 
shown  in  Fig.  3.16  and  the  syntax  diagrams  in  Fig.  3.17 

3.4  PHYSICAL  UNITS  STATEMENTS 

The  extensions  to  FORTRAN  and  PASCAL  Include  a  specification 
capability  for  the  physical  units  with  each  constant  or  variable.  This 
permits  automated  units  consistency  checking  in  expressions  during 
static  analysis.  A  UNITS  statement  performs  no  executable  function  in 
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<input  3tateinent> ;  Input  <varlablt‘  identifi3r>{  ,<variable  identlfier>} 
<output  statement> ! output  <varlable  identifier>{ ,<varl£.ble  ldentlfier>} 


Figure  3.16.  Data  Access  Statements  for  PASCAL 


Figure  3.17.  Syntax  Diagrams  for  PASCAL  Data  Access  Statements 
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a  dynamic  test  and  is  changed  to  a  comment.  Physical  units  are 
expressed  as  a  quotient  of  products  (e.g.,  FT/SEC,  LB*SEC**2,  1/GRAM) 
for  actual  units,  or  the  symbol  1  for  unitless,  or  the  symbol  0  for 
arbitrary  units. 

3.4.1  FORTRAN 

The  syntax  for  the  UNITS  statement  is 

UNITS (VARIABLE-LISTl  -  UNITS-EXPRESSIONl, 

VARIABLE-LIST2  »  UNITS-E>:PRESSI0N2,  . .  .  ) 

where  each  VARIABLE-LIST  is  VARIABLEl  =  VARIABLE2  =  ...  and  each  UNITS- 
EXPRESSION  is  an  arithmetic  expression  Involving  the  physical  units  of 
the  program  variables.  All  UNITS  statements  should  be  Included  in  the 
declaration  section  before  any  executable  statements.  The  second 
statement  in  Fig.  3.1  provides  an  example  of  a  UNITS  statement. 

3.4.2  PASCAL 

Standard  PASCAL  has  provision  for  assigning  types  to  constants  and 
variables.  In  addition  hierarchies  of  data  structures  may  be  constructed 
through  type  declarations.  These  represent  the  computer  implementation 
of  the  program  data  as  opposed  to  a  physical  interpretation  (e.g.,  physical 
units)  of  the  data.  Some  PASCAL  compilers  strongly  enforce  data  types 
and  data  usage  (l.e.,  only  permitted  operations  are  allowed  on  a  specific 
data  type  and  so-called  "mixed  mode"  expressions  are  handled  with  type 
conversion  rules  or  are  considered  to  be  errors).  For  PASCAL,  the  syntax 
of  units  declarations  is  a  qualifier  to  the  simple  type  or  to  the  con¬ 
stant  definition.  The  syntax  for  the  UNITS  qualifier  is  shown  in 
Fig.  3.18,  and  the  syntax  diagram  Is  in  Fig.  3.19.  Figures  3.20  and  3.21 
show  examples  of  usage. 


<constant  deflnition> : : 


<ldentlfier>  ■  <conatant> | 

<ldentiflar>  *  <con8tant>  unlta  <unit8> 

*  <slmple  type>::*  <baslc  type>|<basic  type>  units  <unlts> 

+  <ba8lc  type>::*  <scalar  type> j <subrange  type>|<type  identifier> 

+  <unit8>:: 

<unlts  factor> I <units>/<unlt8  factor>  | 

<units>*<unlts  factor> 

+  <unlt8  factor>::* 

<identif ier> | (<units>)  |  <unit8>**<con8tant> 


) 


Figure  3.18.  UNITS  Qualification  for  PASCAL 
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Figure  3.19.  Syntax  Diagram  for  PASCAL  UNITs  Statements 
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proRrnni  convert  (output) ; 

{generates  a  table  to  convert  between  degrees  centigrade 
and  degrees  fahrcnliclt) 


addin  ”  32  units  degfahrenhcl t ; 

mulby  ”  1.8  uni  t  s  degfahrenhelt/degcentlgrade; 

low  «•  0  units  degeent  igrade; 

high  "  39  units  degeent igrade; 


separator 


begin 


degree : 1 ow. .high; 

write  In  (separator) ; 

for  degree  :»  low  ^  high  ^ 

write(degrce, 'c ' , round (degree*mulby+add in) , ' f ' ) ; 
if  odd  (degree)  then 
writcln 

endlf 
end  for* 
wrlteln; 

write  In (separator) 


Figure  3.20.  Example  of  Constant  Definition  Part  with  Units  Defined 


type  alpha  «  packed  array  (1:10)  £f  char; 
payroll  “  record 

name;  record  first,  last:a]pha 
end  record; 

SS  :  Integer; 

time  worked:  real  units  hours; 
rate:  real  units  dollars/hour ; 
pay:  real  units  dollars; 
end  record; 


Figure  3.21.  Example  of  Type  Definition  Part  with  Units  Defined 
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3.5  IMPLEMENTATION  OF  VERIFIABLE  PASCAL 

'fhe  ability  to  verify  and  execute  Verifiable  PASCAL  programs  is 
possible  by  the  addition  of  a  PASCAL  front  end  to  the  verification  condi¬ 
tion  generator  and  by  a  Verifiable  PASCAL  preprocessor  which  translates 
the  control  structures  and  assertions  into  Standard  PASCAL.  Since  PASCAL 
has  been  selected  as  the  base  language  for  future  Advanced  Quality  Assur¬ 
ance  research  projects,  extensions  and  improvements  to  the  language 
other  than  those  described  in  Secs.  3. 1-3. 4  are  expected  (e.g.,  constructs 
for  fault  tolerant  software  and  for  concurrency) .  This  means  that  the 
Verifiable  PASCAL  should  be  easily  adapted  for  language  changes. 

Several  approaches  to  developing  the  PASCAL  processor  were  con¬ 
sidered: 

1.  Modify  existing  language  tools  (e.g.,  the  PDL-1 
translator  or  the  IFTRAN  translator)  to  analyze  PASCAL 

2.  Design  and  develop  a  new  processor  based  on  the  properties 
of  PASCAL 

14  15 

3.  Use  a  compiler  writing  system  such  as  CWIC  or  CWS  to 
generate  the  PASCAL  processor 

The  existing  language  analyzer  tools  are,  for  the  most  part,  based 
on  FORTRAN  languages  and  extensions  such  as  IFTRAN.  The  PASCAL  language 
with  its  extensions  is  richer  than  FORTRAN  in  the  very  features  most 
Important  to  Advanced  Quality  Assurance  research  (l.e.,  data  structure 
and  control  structure) ,  thereby  adding  complexity  to  the  requirement  for 
the  language  analyzer.  The  existing  front  end  tools  for  the  verification 
condition  generator  are  separate  and  distinct  from  the  translator 
preprocessor.  Because  of  the  complexities  of  PASCAL,  and  the  requirement 
for  analyzing  future  language  expressions,  a  single  language  analyzer  to 
serve  both  functions  (l.e.,  as  front  end  to  the  verification  condition 
generator  and  as  a  preprocessor  for  the  PASCAL  compiler)  was  desirable. 
This  approach  has  the  advantage  of  maintaining  compatibility  in  source 
recognition  between  the  two  functions,  an  improvement  over  existing  tools. 


14  15 

Previous  experience  in  using  CWIC  and  CWS  for  other 
applications^^  demonstrated  the  effectiveness,  flexibility,  and  efficiency 
of  using  a  compiler  writing  system  to  implement  language  analysis  tools 
over  conventional  Implementation  techniques.  CWIC  offers  an  extensive 
library  of  semantic  actions  to  support  syntactic  analysis,  but  presents 
serious  integration  problems  with  other  Software  Quality  Laboratory 
tools.  CWS,  on  the  other  hand,  la  itself  written  in  PASCAL,  is  moderate 
in  size,  and  generates  a  language  analyzer  written  in  PASCAL.  The 
resulting  program  is  easier  to  interface  with  other  tools.  Using  CWS 
also  offered  an  opportunity  to  gain  experience  with  operational  PASCAL 
programs. 

17 

CWS  is  available  in  two  versions:  the  original  bottom-up  system 

18  19 

used  by  TRW  in  RSL  development  and  the  later  top-down  system.  GRC 
had  previously  obtained  both  systems,  conducted  Informal  experiments 
using  the  grammar  of  PASCAL,  and  found  the  top-down  system  to  be  more 
applicable  and  less  restrictive  for  analyzing  large  grammars. 

The  top-down  version  of  CWS  consists  of  a  sequence  of  three  programs. 
The  first  program,  ANALGEN,  accepts  as  input  a  syntax  definition  of  the 
language  grammar  with  imbedded  semantic  actions,  analyzes  the  grammar  for 
completeness  and  conformance  to  the  properties  of  LL(1)  grammars,  prepares 
tables  for  the  later  phase  of  the  system,  and  generates  the  procedures 
which  perform  the  syntactic  analysis  and  semantic  analysis  of  source  text. 
The  second  program,  SCANGEN,  using  the  tables  produced  by  ANALGEN, 
together  with  a  file  of  prototype  code,  constructs  the  lexical  analyzer 
with  its  required  tables  for  reserved  words  and  operators;  it  also 
Incorporates  user-specified  options  for  such  details  as  treatment  of 
blanks,  length,  and  maximum  number  of  Identifiers  and  other  token-related 
definitions.  The  third  program,  ANDEGEN,  completes  the  language  analyzer 
in  preparation  for  compilation.  It  merges  code  generated  by  both  preceding 
phases  together  with  user-supplied  supplementary  declarations  supporting 
semantic  actions  to  produce  the  language  analyzer  pro'jram. 


Within  the  CWS  framework  a  Verifiable  PASCAL  analyzer  has  been 
designed  and  partially  Implemented.  This  analyzer  serves  both  as  a 
front  end  to  the  VCG  and  other  tools  (Incomplete)  and  as  a  translator  to 
standard  PASCAL  (completed).  This  effort  Involves  the  following  activities 

1.  Develop  a  description  of  the  grammar  for  Verifiable  PASCAL 
(see  Appendix  A) . 

2.  Design  standard  PASCAL  templates  for  translation  of 
language  extensions  (see  Appendix  B) . 

3.  Design  and  implement  semantic  actions  for  language  transla¬ 
tion 

4.  Design  the  interface  to  the  VCG  and  other  tools 

5.  Design  and  Implement  semantic  actions  for  Interface 

Items  1  through  3  are  completed  and  work  has  commenced  on  the  remaining 
two. 


The  Verifiable  PASCAL  analyzer  reads  programs  written  in  Verifiable 
PASCAL  and  generates  (1)  a  listing  of  the  input  text  with  imbedded 
syntactic  error  messages,  (2)  a  file  of  the  translated  program  for  input 
to  the  PASCAL  compiler,  (3)  a  detailed  description  of  the  source  text 
suitable  for  input  to  the  VCG  and  other  tools,  and  (4)  a  series  of  reports 
including  an  indented  listing  of  source  text  and  a  directory  showing 
text  groups  (e.g,,  CONST,  TYPE,  VAR,  statements)  and  module  block 
structure.  Examples  of  (1),  (2),  and  (4)  are  shown  in  Figs.  3.22  through 
3.25. 


The  Indented  listing  (Fig.  3.24)  contains  a  sequential  statement 
number  for  the  entire  text,  the  key  for  each  text  group  (H  for  heading, 

C  for  CONST,  T  for  TYPE,  V  for  VAR,  and  S  for  statement),  the  nesting 
level  for  executable  statements,  the  indented  text,  and  the  module  block 
structure  with  sequential  statement  number  within  the  module.  Assertion 
warnings  in  the  executed  program  list  the  appropriate  statement  numbers 
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I  PROGRAM  F0STFIX(INPUT,0UTPUT) ; 

Z  VAR  CHICHA'^; 

3  PROCFrURE  find: 

4  BFGIN 

5  RFPEAT  RFAOCCHI 

6  UNT1HCH<>=  i)AN0  NOT  FOLN(INPUT) 

7  ENO: 

8  PROCFnURt  EXPRESSION? 

9  VAR  CPICHAR? 

10  PROCFCURF  TERM? 

11  PROCFrUR^  FACTOR? 

12  BEGIN 

13  IF  CH=il£  THEN 

14  find: 

15  expression; 

16  ELSE 

17  MRITE(CH»; 

18  ENDIF? 

19  FINO 
?0  ENO? 

21  (*FACTCR*> 

22  BEGIN  FACTOR? 

23  WHILE  CH=:*=  00 

24  FIND? 

25  FACTOR? 

26  WRITF.(r*EI 

27  ENOWHILF 

28  ENO? 

29  (•TERM*! 

30  BEGIN 

31  TERM? 

32  WHILE  ICHs=^=IOR(CHs=-rT  00 

33  0PI=CH?.  ..  V 

34  FINO?  '  ’ 

35  TERM? 

36  WRITF(CP»? 

37  FMO  WHILE 

38  ENO? 

39  (•EXPRESSION*) 

40  BFGIN 

41  FINO? 

42  REPEAT 

43  HRITf  (r  =)  ; 

44  EXPRESSION? 

45  WPITEIN 

46  UNTIL  CH==.= 

47  ENO. 


Figure  3.22.  Example  of  Input  Text  Listing  from  Verifiable  PASCAL 
Preprocessor 
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CCC006  PROGFAM  POSTFIX  I  INPUT  ,  OUTPUT  »  ; 

0!)c vap 

OOC^oi.  CH  !  CHAR  ; 
caL..b5  ASGfFT  V.  BOOLEAN  ? 

030466  PROCEOUPE  FIND  ; 

030003  VAR 

030  3  0  3  ASSERT  'A  BOOLEAN  ; 

C3C0Q4  BF.GIN 
0000Q4  REPEAT 
000306  BEGIN 
03CQ06  READ  (  CH  J 
000  3  1  3  ftlD 

Q03013  UNTIL  (  CH  <>  =  =  I  AND  NOT  EOLN  (  INPUT  » 

000315  ENO  ; 

,030025  PROCECURE  EXPRESSION  ? 

000003  VAR 

000003  OP  t  CHAR  1 

000004  ASSEPT  */.  BOOLEAN  \ 

00C3C5  PRCCFC'JPE  TERN  \ 

000303  VAR 

0  3  3  303  ASSEFT  7,  BOOLEAN  ; 

030004  PRQCrrURE  FACTOR  ; 

000303  VAR 

'>30003  ASSEPT  7.  BOOLEAN  T 
000004  BEGIf. 

QQ0DO4  IF  CH  =  =(=  THEN 
030310  BEGIN 

cocoia  FIND  ; 

000311  EXPRESSION  ? 

030312  ENO 

000012  ELSE 

000013  BEGIT 

0300  13  V.RITE  <  CH  »  J 

000017  ENO  ('ENOIF  *)  ; 

000017  Fine 
003317  ENO  ? 

000026  BEGIN 
030026  FACTCP  \ 

000007  WHILE  CH  »  =•=  DO 
000311  BEGIN 
030011  FIND  ? 

030012  FACTCP  ? 

C30314  WRITE  E  =•=  » 

C0CC16  EMC  <*EHOWHIL£  •) 

OOCOIS  ENO  ; 

030025  BEGIN 
000025  TERM  I 

00C307  WHILE  (  CH  »  =♦=  >  OR  «  CH  «  =-=  )  DO 
030314  BEGIN 
000314  CP  1=  CH  J 
0QC017  FIND  \ 

000020  TERM  T 

030022  WRITE  <  OP  »  T 

00C026  ENO  (’ENO  WHILE  •> 

000026  END  \ 

303037  BEGIN 
000337  FIND  ; 

003023  REPEAT 
030023  BEGIN 
000023  WRITE  C  i  =  I  I 
000025  EXPRESSION  % 

000026  WRITELN 
000326  FNO 
000027  UNTIL  CH  s 
000327  ENO  . 

Figure  3.23.  Example  of  Translated  Text  Produced  by  Verifiable 
PASCAL  Preprocessor 
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PASCAL  Preprocessor 


MODULE  TEXT  GROUPS  AND  UlOCK  STRUCTURE 


HEAD 

LABEL  COK'ST 

TYPE 

VAR 

BEGIN. 

..END 

STRUCTURE 

1 

0  0 

(1 

2 

41 

ki 

P03TEIX 

t* 

0  0 

0 

Q 

5 

9 

.  PIMD 

10 

0  Q 

0 

11 

32 

40 

.  EXPRESSION 

13 

0  0 

0 

0 

24 

31 

.  .  TERM 

14 

0  0 

0 

0 

15 

?3 

.  .  .  FACTOR 

Figure  3.25.  Example  of  Source  Text  Directory  and  Module  Structure 
Report 


and  module  names  shown  on  the  indented  listing.  The  directory  report 
(Fig.  3.25)  shows  the  text-wide  statement  number  which  begins  each  text 
group  for  each  module  and  the  module  block  structure  depicting  the  scope 
of  the  module. 

The  user  may  select  from  various  options  by  preceding  the  text  with 
an  OPTIONS  statement.  The  keyword  ASIS  is  a  mnemonic  for  "as  is."  The 
Implemented  translation  options  include: 

CONTROL  ■  ON  (default) ,  translate  Verifiable  PASCAL  control 

statements  (IF. . .ORIF. . .ENDIF,  etc.)  to  standard  PASCAL 

CONTROL  «•  ASIS,  pass  control  statements  without  translation 

ASSERT  »  ON  (default),  translate  assertion  statements  to  executable 
code 

ASSERT  -  OFF,  translate  assertion  statements  to  comments 

ASSERT  ■  ASIS,  pass  assertion  statements  without  translation 
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UNITS  =  OFF  (liefault) ,  translate  units  qualifiers  to  comments 

UNITS  =  ASIS,  pass  units  qualifiers  without  translation 

RIGHTS  =  OFF  (default),  translate  data  access  rights  statements 
(INPUT,  OUTPUT)  to  comments 

RIGHTS  *  ASIS,  pass  rights  statements  without  translation 

For  translation  to  executable  text  the  user  normally  selects  the  default 
options.  For  interface  to  other  tools  the  user  selects  the  option  appro¬ 
priate  for  the  target  tool.  Since  the  analyzer  design  is  not  yet  complete 
for  the  interface,  user  options  for  the  interface  have  not  been  specified. 


I 


) 


I 


4  STATIC  ANALYSIS 

Once  the  syntax  analysis  of  a  program  Is  without  errors,  the  second 
step  in  developing  verifiable  software  is  static  analysis,  as  shown  in 
Fig.  2.1.  The  Software  Quality  Laboratory  provides  a  set  of  consistency 
checking  techniques  that  detect  a  wide  variety  of  errors  and  are  appli¬ 
cable  to  large  software  systems.  They  also  detect  the  Incorrect  use  of 
variables  when  assertion  statements  are  add>2d  to  a  program.  Data  access 
statements  and  unit  qualifiers  provide  formalized  representations  of  soft¬ 
ware  specifications  and  programming  assumptions  at  the  source  language - 
level  of  detail.  Source  language  conventions  and  good  programming  prac¬ 
tices  also  provide  general  software  specifications.  Inconsistencies  be¬ 
tween  the  software  and  its  specifications  are  automatically  detected  and 
reported  by  the  static  analysis  tools  in  the  Software  Quality  Laboratory. 

The  types  of  Inconsistencies  which  are  detected  include: 

•  Operations  on  variables  with  mismatched  physical  units 

•  Variables  used  prior  to  being  assigned  a  value  or  set 
and  not  used 

•  Actual  use  of  a  variable  which  differs  from  asserted  use 

•  Mismatched  data  types 

•  Unreachable  statements 

•  Infinite  loop  constructs 

•  Inconsistent  actual  and  formal  parameters 

The  Laboratory  provides  a  command  language  to  control  the  static 

analysis  tools.  Commands  may  be  entered  as  data  input  cards  during 

20 

batch  processing,  or  interactively  through  the  Anagraph  console.  Use 
of  the  Software  Quallry  Laboratory  commands  is  described  in  Sec.  4.1.  A 
static  analysis  tool  which  performs  units  checking  by  validating  arith¬ 
metic  expressions  for  consistent  physical  units  is  Included.  The  physical 
units  consistency  analysis  algorithm  which  is  implemented  in  the  Laboratory 
is  discussed  in  Sec.  4.2.  Another  tool  which  performs  set  and  use  checking 


by  uncovering  possible  use  before  set  conditions  and  similar  variable  use 
abnormalities  is  also  included.  Section  4.3  describes  the  algorithm  usee 
to  perform  variable  use/set  analysis  (data  flow  analysis).  The  Software 
Quality  Laboratory  provides  a  common  data  base  which  Integrates  the  use¬ 
fulness  of  static  analysis  tool'*..  Set/use  analysis  automatically  gener¬ 
ates  the  actual  use  of  program  variables.  This  allows  data  access  asser¬ 
tions  to  be  compared  with  actual  variable  usage.  The  multiple  module 
data  base  and  program  structure  information  required  for  set/use  analysis 
allow  formal  and  actual  parameter  checking  as  well  as  structural  consis¬ 
tency  analysis. 

4.1  STATIC  ANALYSIS  COMMANDS  AND  REPORTS 

The  static  analysis  techniques  available  in  the  Software  Quality 
Laboratory  include: 

•  Units  checking  which  validates  expressions  for  consistent 
physical  units. 

•  Set  and  use  checking  which  uncovers  possible  use  before 
set  conditions  and  similar  program  abnormalities. 

•  Assertion  use  versus  actual  use  which  checks  INPUT  and  OUTPUT 
statements  against  actual  usage  of  these  variables  within  the 
module  and  validates  that  unmentloned  global  variables  are 
not  referenced. 

•  Type  and  mode  checking  which  identifies  possible  misuse  of 
constants  and  variables  in  expressions,  assignments  and 
Invocations. 

•  Graph  checking  which  Identifies  possible  errors  in  program 
control  structure  such  as  unreachable  code. 

•  Invocation  checking  which  validates  actual  invocations 
against  formal  declarations;  checking  for  consistency  in 
number  of  parameters  and  type  and  intermodule  Input/output 
consistency. 
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The  Software  Quality  Lab  analysis  tools  are  controlled  using  a 
command  language.  Static  analysis  is  executed  with  the  command 

STATIC 

Seven  options  may  be  selected.  Five  are  selected  "ON"  by  default,  and 
two  "OFF".  To  change  any  of  the  default  settings,  it  is  necessary  to 
Insert  the  appropriate  command  from  the  following  list  before  the  com¬ 
mand  STATIC  (default  values  are  underlined): 

STATIC , UNITS=OFF/ON . 

STATIC, SET /USE=OFF /ON. 

STATIC , ASSERT/ACTUAL=OFF/ON . 

STATIC, MODE-OFF /ON. 

STATIC,  CALL-OFF/^. 

STATIC , GRAPH-OFF/ra . 

STAT IC , LOOP-OFF /ON . 

Separate  commands  are  necessary  for  changing  the  default  for  each 
type  of  analysis. 

The  rest  of  this  section  describes  the  analysis  performed  by  each 
of  the  connands.  Illustrates  the  kinds  of  errors  which  can  be  detected, 
and  explains  the  static  analysis  reports. 

4.1.1  Physical  Units 
Description 

Requiring  that  each  local  variable  and  each  global  variable  be 
specified  in  terms  of  the  physical  units  it  represents  (if  any)  allows 
comprehensive  checking  of  the  consistency  of  units.  This  type  of  check¬ 
ing  is  particularly  relevant  to  technical  software  where  many  physical 
properties  are  represented  and  there  are  many  possibilities  uf  confusion 
over  units.  Units  can  be  checked  not  only  in  one  module,  but  across  two 
or  more  modules  if  each  module  contains  a  description  of  the  units  for 
each  physical  variable  it  refers  to,  in  the  form  of  an  assertion: 
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UNITS  (variable  list  1  =  units  expression  1, 

variable  list  2  =  units  expression  2,  ...) 

An  inconsistency  in  units  is  indicated  if  unlike  units  are  added,  sub¬ 
tracted,  or  compared.  The  physical-units  analysis  compares  the  right 
and  left  side  of  assignment  statements,  the  right  and  left  side  of  re¬ 
lational  operations,  and  actual  and  formal  parameters.  For  convenience 
in  stating  UNITS  assertions,  all  constants  are  assumed  to  be  unitless, 
except  for  zero,  which  will  match  any  units  expression.  A  variable  is 
declared  unitless  by  stating  that  its  units  expression  is  the  constant 
1,  as  in  UNITS  (PI  =  1). 

Option  Selection 

The  physical-units  analysis  is  not  performed  unless  the  option  is 
selected  by  the  command 

STATIC, UNITS  -  ON. 

Reports 

The  units  asserted  to  be  associated  with  each  variable  appear  in 
the  Symbol  Analysis  Summary  of  the  Static  Analysis  report.  This  report, 
for  a  subroutine  called  XAMPL,  is  shown  in  Fig.  4.1.  The  last  column 
shows  the  asserted  units  for  variables  R,  H,  A,  and  V. 

If  a  physical  quantity  is  asserted  to  be  in  units  other  than 
actually  calculated,  the  unltn  consistency  check  will  identify  such  an 
inconsistency  within  a  given  statement,  and  also  Indicate  interface 
errors  which  arise  when  defined  units  of  parameters  passed  between 
routines  do  not  match.  All  such  inconsistencies  will  be  reported  in 
the  Statement  Analysis  Summary  of  the  Static  Analysis  report. 
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Figure  4.1.  Symbol  Analysis  Summary 


Figure  4.2  shows  this  report  for  subroutine  CIRCLE.  An  error 
message  has  been  printed  to  show  that  AREA  has  been  defined  as  FEET**2 
and  that  the  square  of  RADIUS  would  be  IKCHES**2.  The  units  on  both 
sides  of  an  equation  must  be  equivalent. 

Figure  4.3  shows  another  type  of  units  error,  in  subroutine  ARITH. 
The  inconsistency  in  the  spelling  of  FEET  has  resulted  in  the  same  type 
of  operation  error  as  before. 


S'ATIC  analysis 


SUbRCUTINE  circle  t  RADIUSi  AREA  ) 


1 

subroutine  circle  (  RAUIUS.  AREA  ) 

2 

UMTS  (  KACIUS  =  INCHFSt  AREA  =  FEET  «*  2i  PI  b  1  ) 

3 

CATA  pi  /  3.1416  / 

4 

INPUT  (  RACIUS  > 

5 

C 

6 

AREA  =  Rl  «  RACIUS  •«  2 

UMTS  ERROR 

=  OPERATION  WITH  INCONSISTENT  UNITS 
(  FEET  *  FEET  ) 

(  INCHES  *  INCHES  ) 


7 

C 

8 

OUTPUT  (  AREA  ) 

9 
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GRAPH  checking 
CALL  checking 

units  consistency 
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Figure  4.2.  Units  Error  Report  due  to  Incorrect  Units 


SIATIC  analysis 

SULKCUTINE  AHTIH  { 

area,  lElOhT,  VOLUME  > 
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3 

4  C 

5 

SUBROUTINE  ARITII  J  AREA,  HfiGHT, 
UNITS  (  AREA  =  FT  2,  HETGHT  = 
INPUT  (  AREA,  HEIGHT  ) 

VOLUME  =  AREA  •  HEIGHT 

voluml  ) 

FEET,  VOLUME  =  FEET  •*  3  ) 

-  UNITS  ERROR 
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Figure  4.3.  Units  Error  Report  due  to  Misspelling 


Figure  4.4  shows  that  the  units  analysis  of  the  routine  XAMPL, 
which  calls  CIRCLE  and  ARITH,  has  discovered  the  inconsistency  in  units 
of  the  parameters  resulting  from  the  two  previous  errors: 

1.  R,  correctly  specified  as  FEET,  corresponds  to  RADIUS, 
which  was  incorrectly  specified  as  INCHES. 

2.  A  is  defined  as  FEET**2  and  AREA  as  FT**2. 


SIMIC  analysis 
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INPUT  (  Hi  H  ) 

call  circle  (  R,  a  ) 

-  UNITS  ERROR 

-  s  operation  wIth  Inconsistent  units 
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•  INCHES 

6 

call  AKIIH  (  A«  H.  V  ) 

-  UNITS  Error 
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7  C 

6 

9 

10 
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return 
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GrtAFh  ChLCKlNC  0  0 
GALL  CHbCKlUG  2  0 
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MOOL  checking  0  C 


Figure  4.4.  Units  Error  Report  due  to  Mismatched  Parameter/Argument 


4.1.2  SET/USE 
Description 

Just  as  misuse  of  physical  units  a  source  of  many  errors  in  soft¬ 
ware  systems,  so  Is  improper  use  of  program  variables.  The  technique  of 
data  flow  analysis  detects  anomalies  in  the  use  of  variables  such  as 

•  Reference  to  a  variable  before  it  has  been  assigned 
a  value 

•  Failure  to  reference  a  variable  after  it  had  been 
assigned  a  value 

Causes  range  from  simple  misspelling  to  mismatched  argument  or 
parameter  lists.  Not  only  are  these  more  obvious  errors  detected,  but 
also  more  subtle  inconsistencies  can  be  found  because  the  flow  of  data 
between  procedures  is  examined.  When  no  data  flow  anomalies  have  been 
uncovered,  their  absence  can  be  assured. 

Option  Selection 

The  option  to  perform  the  SET/USE  analysis  of  all  variables  is 
automatically  selected  with  the  command. 

STATIC. 

The  option  may  be  turned  off  by  the  command 
STATIC, SET/USE  -  OFF. 


Report 

Figure  4.5  is  a  listing  of  a  subroutine  SETUSE.  The  S)nnbol  Analysis 
Summary  from  the  Static  Analysis  report  on  SET/USE  (Fig.  4.6)  Indicates 
that  neither  DIAMTR  nor  PI  had  been  assigned  a  value  being  used. 


80 


»«•  <• 


iLeHCLTlt.E  StTLiL 


hAtlUS  :  Cll«^  TR  /  2 
/>P(.A  s  r*!  •  nACIIJ&*«2 

r-Hir.T  1.  (HAriLsi  area  > 

1  FC*<>'AT  «  2  <F6.i»  ) 

f*  t  T  uMi* 
cNC 


Figure  A. 5.  Subroutine  SETUSE  Statement  Listing 
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Figure  4.6.  Symbol  Analysis  Summary  with  Uninitialized  Variables  Errors 


4.1.3  ASSERT /ACTUAL 
Description 

A  third  type  of  interface  consistency  checking  is  to  compare  the 
actual  use  of  global  variables,  as  determined  by  the  data  flow  analysis 
of  variables  (see  Sec.  4.1.2),  with  the  asserted  use. 

The  asserted  use  of  a  variable  is  stated  in  INPUT  and  OUTPUT 
assertions: 

INPUT  (variable  list) 

OUTPUT  (variable  list) 

An  INPUT  variable  whose  value  may  be  changed  in  the  routine  should  also 
be  included  in  the  OUTPUT  variable  list. 

An  INPUT  assertion  states  that  the  variables  named: 

•  Are  global  variables  (either  parameters  or  common  variables) 

•  Will  have  values  whenever  the  routine  is  called 

•  Will  not  be  changed  In  the  routine  (unless  they  have  also 

been  listed  in  the  OUTPUT  assertion) 

•  Are  the  only  global  variables  used  in  this  routine 

An  OUTPUT  assertion  states  that  the  variables  listed: 

•  Are  global  variables  (either  parameters  or  common  variables) 

•  Will  be  assigned  a  value  in  the  routine 

•  Will  not  be  used  to  supply  a  value  to  the  routine, 

unless  they  have  also  been  listed  as  INPUT  variables 

•  Are  the  only  global  variables  set  In  this  routine. 


A  listing  of  subroutine  CIRCLE  appears  In  I'lg.  4.7. 
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Figure  4.7.  Statement  Listing  for  CIRCLE 


In  the  CIRCLE  routine,  the  assertion 
INPUT  (RADIUS) 

Is  consistent  If  the  first  use  of  RADIUS  on  each  path  In  CIRCLE  Is  one 

of  the  following: 

1.  On  the  right-hand  side  of  an  assignment  statement 

2.  Within  a  decision  predicate 

3.  In  1  subroutine  or  function  reference  where  RADIUS  Is 
used  as  Input 

The  assertion 

OUTPUT  (AREA) 

Is  consistent  If  any  use  of  AREA  In  CIRCLE  Is  one  of  the  following: 

1.  On  the  left-hand  side  of  an  assignment  statement 

2.  In  a  READ  statement 

3.  In  a  subroutine  or  function  reference  where  AREA  Is  used 
as  output. 
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Asset '"Ions  about  the  use  of  arrays  apply  to  the  whole  array,  not 
individual  erements  of  the  array.  This  is  necessary  because  data  flow 
analysis  does  not  distinguish  the  actual  use  of  individual  array  elements. 

Option  Selection 

The  asserted /actual  emphasis  is  not  performed  unless  the  option 
is  selected  by  the  command 

STATIC ,ASSERT/ACTUAL=ON. 

Report 

The  report  provided  by  this  option  indicates  the  number  of  incon¬ 
sistencies,  either  as  errors  or  warnings.  For  subroutine  ARITH,  listed 
in  Fig.  4.8,  the  Symbol  Analysis  Summary  is  shown  in  Fig.  4.9. 

The  first  error  occurs  because  HEIGHT  has  been  listed  incorrectly 
as  an  OUTPUT  variable;  its  actual  use  indicates  that  it  is  an  INPUT 
parameter  which  supplies  a  value  for  the  computation  of  VOLUME. 

The  second  error  results  because  TOTAL  has  not  been  listed  as 
either  INPUT  or  OUTPUT  and  hence  has  no  asserted  use.  Because  it  is  a 
global  variable  (a  parameter),  it  must  be  declared. 

The  third  error  is  of  the  SET /USE  type  described  in  Sec.  4.1.2. 
NUMBER  is  neither  in  common  nor  a  parameter  and  so  is  a  local  variable; 
however,  it  is  used  in  the  computation  of  TOTAL  before  it  has  been  given 
a  value. 
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Figure  4.8.  Statement  Listing  for  ARITH 
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Figure  4.9.  Symbol  Analysis  Summary  with  Variable  Use  Assertion  Errors 
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4.1.4  MODE 
Description 

Potential  errors  which  result  from  inconsistencies  in  the  mode  of 
variables  (REAL,  INTEGER,  etc.)  can  be  found  in  the  static  analysis 
checking  of  expressions. 

Option  Selection 

Mode  checking  is  one  of  the  options  which  is  Included  ih  the  an¬ 
alysis  performed  by  the  command,  STATIC.  To  turn  off  the  option 

STATIC,MODE“OFF. 

must  be  commanded  before  the  STATIC  command. 

Report 

The  Symbol  Analysis  Summary  of  the  Static  Analysis  report  lists  the 
name  and  mode  of  each  variable  which  has  been  set  or  used  in  a  routine. 

A  mode  inconsistency  causes  a  warning  to  be  printed  immediately  ) 

following  the  statement  in  which  it  occurs  in  the  listing,  and  the 
number  of  warnings  is  tabulated  in  the  Statement  Analysis  Summary. 

Figure  4.10  is  a  listing  of  subroutine  MODE;  it  contains  two  mode 
errors,  as  can  be  seen  in  Fig.  4.11. 
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Figure  4.10.  Statement  Listing  for  Subroutine  MODE 
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Figure  4.11.  Statement  Analysis  Summary  with  Mode  Warnings 
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4.1.5  CALL 
Description 


Another  of  the  static  analysis  options  specifies  interprocedural 
checking  of  subroutine  or  procedure  invocations  to  reveal  situations 
which  may  lead  to  errors,  such  as: 

•  The  number  of  parameters  listed  does  not  agree  with 
those  of  the  routine  called. 

I 

•  The  mode  of  an  actual  parameter  does  not  match  that 
of  the  corresponding  formal  parameter. 

•  A  parameter  is  listed  in  the  calling  argument  list 
as  a  single,  non-subscripted  variable  but  is  used 
in  the  routine  as  an  array. 

•  The  routine  called  does  not  exist  in  the  set  of  modules 
being  tested. 

Option  Selection 

Call  checking  of  parameter  lists  is  automatically  Included  in  the 
analysis  specified  by  the  STATIC  command.  If  the  option  is  not  wanted, 
it  is  turned  off  by  the  cotnnand 

STATIC, CALL-OFF. 


Report 

Figures  4.12  and  4.13  are  listings  of  Subroutines  CIRCLE  and  ARITH 
(somewhat  different  from  those  given  in  Figs.  4.7  and  4.8). 
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Figure  A. 12.  Statement  Listing:  Subroutine  CIRCLE 
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Figure  A. 13.  Statement  Listing:  Subroutine  ARITH 


A  report  showing  interface  Inconsistencies  among  three  modules  is 
generated  in  the  Statement  Analysis  Summary  for  Subroutine  XAMPL,  Fig.  A.IA. 

The  first  error  occurs  because  CIRCLE  has  two  arguments  (RADIUS  and 
AREA)  and  the  Invocation  has  one.  Two  errors  result  from  the  invocation 
of  Subroutine  ARITH.  The  variable  H  has  been  declared  as  an  integer, 
but  HEIGHT,  the  variable  in  ARITH  which  corresponds  to  H  ,  is  real. 

The  variable  V  is  a  single,  non-sub scripted  variable,  but,  in  ARITH, 

VOLUME  has  been  dimensioned  as  an  array. 
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Figure  A. 14.  Statement  Analysis  Summary  Showing  Calling  Errors 


Subroutine  FINISH  was  not  included  in  the  set  of  routines  examined 
in  this  static  analysis.  Although  this  is  not  an  actual  error,  a  message 
is  printed  on  the  right  side  of  the  report  as  a  reminder. 

A. 1.6  Unreachable  Statements 
Description 

An  obvious  consistency  check  is  that  of  structural  consistency. 

The  program  graph  for  each  module  can  be  checked  to  see  that  all  state¬ 
ments  are  reachable  from  each  statement.  Unreachable  statements  repre¬ 
sent  extra  overhead  in  terms  of  memory  space  required  for  a  module,  while 
statements  from  which  the  exit  cannot  be  reached  represent  potentially 
catastrophic  system  failures. 

Option  Selection 

The  checking  for  unreachable  statements  is  automatically  Included 
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In  the  analysis  specified  by  the  STATIC  command.  If  the  option  is  not 
wanted,  it  is  turned  off  by  the  command 

STATIC, GRAPH=OFF 


Report 

Figure  4.15  is  a  statement  listing  of  NOPATH.  In  this  subroutine. 
Statement  7  is  a  RETURN  statement.  The  two  executable  statements  which 
follow  it  are  unreachable,  and  a  warning  message  is  printed  for  each  in 
the  Statement  Analysis  Summary  (Fig.  4.16). 
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Figure  4.15.  Statement  Listing  of  Subroutine  NOPATH 
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Figure  4.16.  Statement  Analysis  Summary  with  Unreachable  Statement 
Errors 
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4.1.7  Loop  Constructs 
Description 

I 

One  of  the  most  frustrating  and  common  errors  is  an  infinite  loop 
construct.  A  check  on  structural  consistencies  determines  if  this  pos¬ 
sibility  exists. 

Option  Selection 

This  option  is  on  when  the  STATIC  analysis  is  performed  unless  it 
has  been  turned  off  with  the  comnand 

STATIC,  LOOP=OFF. 


Report 

No  report  is  generated  unless  the  possibility  of  an  infinite  loop 
construct  exists.  If  such  a  construct  has  been  located,  a  loop  analysis 
report  is  generated  containing  a  warning  message  and  the  statements  of 
the  loop  in  question. 

Some  errors  of  this  type  are  not  immediately  obvious  and,  therefore, 
are  difficult  to  detect.  One  such  error  is  in  subroutine  SEARCH,  listed 
in  Fig.  4.17.  Figure  4.18  shows  the  report,  which  Includes  the  portion 
of  the  code  where  there  may  be  an  infinite  loop.  The  infinite  loop 
would  occur  when  the  ELSE  path  is  taken;  LOOKUP  is  set  to  I  ,  but 
neither  M  nor  N  is  modified,  so  that  the  conditions  of  the  loop  would 
be  infinitely  repeated. 


92 


ro. 

LEVEL 

LALEL 

siatlrem  text... 

1 

SUcROUriKE  search  (  AIlKAYt 

length*  Xi  LOOrUP  ) 

2 

IMLOEH  ARRAY  (  1  ).  x 

3 

c 

4 

K  =  1 

K 

A  =  LFNGIh 

b 

fcHlLE  (  R  ♦  1  .LT.  N  ) 

7 

( 

1) 

.  1  =  1  R  ♦  N  >  /  ? 

6 

( 

11 

.  tf  (  X  •LT.  ARRAY  (  I  ) 

) 

9 

( 

2) 

.  .  t.  =  1 

10 

( 

1) 

.  GRIP  (  X  .GT.  array  I  I 

)  ) 

11 

( 

2) 

.  .  M  =  I 

12 

< 

1» 

.  EL4L 

13 

( 

2) 

.  .  LCLKCP  =  1 

14 

( 

1) 

.  ENr.IF 

15 

ENCLHlLE 

lb 

c 

17 

RETiJR^ 

lb 

ENl 

Figure  4.17.  Statement  Listing  of  Subroutine  SEARCH 
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Figure  4.18.  Loop  Analysis  Warning  Report 


A.  2  PHYSICAL  UNITS  CONSISTENCY  ANALYSIS 

Physical  units  checking  is  an  excellent  example  of  consistency 
analysis  using  a  partial  program  specification  at  the  source  language 
level  of  detail.  The  units  tester  uses  UNITS  statements  (described  in 
Sec.  3)  to  associate  specified  physical  units  with  program  variables. 

If  program  variables  RGB,  RHO,  GR2,  and  BETA  are  specified  by 

UNITS (RGB  *  1/FT) 

UNITS (RHO  =  (SEC**2)/LBS) 

UNITS(GR2  =  FT/(SEC**2)) 

UNITS(BETA  =  LBS/(FT**2)) 

then  the  computation  of  RGB  as 

RGB  =  (-RH0*GR2)/BETA 

is  consistent.  This  can  be  verified  by  substitution  of  unit  qualifiers 
and  simplification.  The  right-hand  side  of  this  assignment  statement 
becomes 

(-( (SEC**2) /LBS)*FT/ (SEC**2) ) / (LBS/ (FT**2) )  ) 

cancelling  the  (SEC**2)  terms  results  in 
(-FT/LBS)/(LBS/FT**2) 

cancelling  common  FT  and  LBS  terms,  and  dropping  the  minus  sign  yields 
(1/FT) 

which  matches  the  units  description  of  the  left-hand  side  of  the  assign¬ 
ment  statement. 

An  algorithm  to  automatically  perform  this  substitution  and  simpli¬ 
fication  process  has  been  Implemented  in  the  Software  Quality  Lab.  The 
physical  units  checking  process  transforms  each  arithmetic  expression  into 
a  tree  with  unit  qualifiers  as  nodes.  Unit  qualifiers  associated  with 
variables  are  specified  with  UNITS  statements.  Figure  4.19  indicates 
physical  units  assertions,  the  statement  to  be  analyzed  and  the  units 
tree  which  results. 

) 
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Figure  4.19.  Physical  Units  Tree 


The  physical  units  simplification  and  normalization  rules  which 
are  applied  by  the  algorithm  are  shown  in  Fig.  20  and  Fig.  21.  Since 
like  units  can  be  added  or  subtracted,  the  addition  rule  in  Fig.  20 
removes  addition  and  subtraction  operators  from  the  physical  units  tree. 
Like  units  can  also  be  compared.  The  relational  rule  in  Fig.  4.20 
replaces  relational  operators  (greater  than,  equal,  not  equal,  etc.) 
with  the  value  TRUE.  The  addition,  subtraction,  or  comparison  of  un¬ 
like  physical  units  Immediately  results  in  a  units  inconsistency. 
Additional  simplification  rules  include  cancellation  of  like  units  in  a 
numerator  and  denominator,  dropping  unary  minus  and  unary  plus  operators, 
and  logical  operation  simplification. 


Normalization  rules  are  limited  to  multiplication,  division,  and 
exponentatlon  operators  since  all  other  operators  are  simplified  out. 
The  cummulatlve  property  of  multiplication  is  used  to  lexically  order 
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Figure  4.20.  Physical  Units  Simplification  Rules 
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all  product  terms  (Fig.  4.21).  Exponentiation  operations  are  converte  , 
to  an  equivalent  product  term  (this  limits  the  analysis  to  Integer  expon¬ 
ents)  .  The  normal  form  for  units  expressions  is  a  quotient  of  ordered 
product  terms.  The  multiplication  and  division  normalizations  in  Fig. 

4.21  maintain  this  form  by  moving  all  division  operators  to  the  root  of 
the  physical  units  tree  being  analyzed. 

The  physical  units  consistency  analyzer  applies  these  rules  as  the 
physical  units  tree  is  walked.  Each  subtree  of  a  nonterminal  node  must 
be  in  normalized,  simplified  form  before  the  rules  are  applied  to  that  non¬ 
terminal  node.  A  recursive  description  of  the  algorithm  is  given  in 
Fig.  4.22. 
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Figure  4.22.  Physical  Units  Consistency  Analysis  Algorithm 


A. 3  DATA  FLOW  ANALYSIS 

Improper  use  of  program  variables  is  a  major  souce  of  errors  in 
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large  software  systems.  The  technique  of  data  flow  analysis  detects 
anomalies  in  the  use  of  variables  such  as  references  to  a  variable  before 
it  has  been  assigned  a  value. 

The  results  of  data  flow  analysis  technique  in  the  Software  Quality 
Laboratory  are  similar  to  that  performed  by  the  DAVE  system.  A  leaf-first 
analysis  of  the  system  calling  tree  is  performed.  While  the  DAVE  system 
analyzes  each  module  with  a  variable-by-variable  depth  first  search,  the 
Software  Quality  Laboratory  performs  a  parallel  analysis  of  all  variables 
in  a  module.  The  resulting  computation  time  can  be  several  orders  of 
magnitude  faster  with  the  parallel  analysis  technique. 

Both  techniques  are  applicable  to  FORTRAN  source  code,  DAVE  is 
limited  to  ANSII  standard  FORTRAN.  The  Software  Quality  Laboratory  can 
analyze  common  extensions  to  ANSII  FORTRAN,  including  a  dialect  of  struc¬ 
tured  FORTRAN (IFTRAN) .  The  Software  Quality  Laboratory  techniques  in¬ 
clude  optional  consistency  checking  of  actual  variables  usage  and  desired 
variable  usag<^'.  DAVE  does  not  provide  this  additional  check. 

Data  flow  analysis  classifies  the  usage  of  all  program  variables. 

A  variable  is  used  as  output  (to  receive  a  value)  if  any  of  its  uses  is 
one  of  the  following; 

1.  On  the  left-hand  side  of  an  assignment  statement 

2.  In  an  initialization  statement  such  as  a  DATA  statement 

3.  In  a  READ  statement 

A  variable  is  used  as  input  (to  supply  a  value)  if  its  first  use  on 
some  path  is  one  of  the  following: 

1.  On  the  right-hand  side  of  an  assignment  statement 

2.  Within  a  decision  predicate 

3.  Within  a  WRITE  statement. 


A  path  originates  at  the  entry  to  the  software  system,  follows  one  of 
many  structurally  possible  routes  thru  the  software,  and  terminates  at 
ah  exit  from  the  software  system.  A  path  will,  in  general,  go  through 
more  than  one  module  of  a  multi-module  software  system. 

A  naive  approach  to  data  flow  analysis  is  to  identify  all  possible 
paths  and  compute  the  use  of  each  program  variable  on  each  path.  This 
approach  quickly  runs  into  the  combinatorics  problem  of  too  many  paths 
in  even  moderately  sized  software  systems.  Several  techniques  are  avail¬ 
able  to  dramatically  improve  the  efficiency  of  data  flow  analysis.  The 
first  technique  uses  a  software  sys^em'8  intermodule  calling  structure. 

The  calling  structure  is  represented  as  a  tree  whose  root  is  the  main 
module  in  the  software  system.  The  calling  tree  is  then  analyzed  in  a 
bottom-up  fashion.  Modules  which  do  not  Invoke  any  other  modules  (leaf 
modules)  are  analyzed  first.  Then  modules  which  Invoke  only  leaf  modules 
are  analyzed,  etc.  After  a  module  has  been  analyzed,  it  can  be  represented 
in  terms  of  its  variables  and  how  they  are  used  rather  than  as  a  set  of 
statements  with  an  Inherent  structure.  Each  module  is  only  analyzed  once 
when  this  techlque  is  used.  A  similar  technique  allows  each  statement  in 
each  module  to  be  analyzed  only  once  during  a  complete  data  flow  analysis 
for  all  program  variables.  This  technique  is  based  on  (but  not  limited 
to)  a  well-structured,  single-entry,  single-exit  program  graph.  Data  flow 
analysis  proceeds  sequentially  thru  each  statement  in  a  well  structured 
program.  The  use  state  of  each  program  variable  is  updated  as  statements 
are  sequentially  analyzed.  Control  statements  from  which  several  parallel 
paths  originate  cause  parallel  use  states  to  be  computed.  Control  state¬ 
ments  at  which  several  parallel  paths  rejoin  cause  parallel  use  states  to 
be  combined  into  one  use  state.  Data  flow  analysis  of  the  following 
statements 
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1.  A  =  X 

2.  IF(A  .GT.  Y) 

3.  A  =  Y 

4.  ELSE 

5.  Y  *  A 

6.  END  IF 

would  be  performed  in  the  following  steps: 

1.  Statement  1  uses  X  as  input  and  A  as  output. 

2.  Statement  2  adds  use  of  Y  and  A  as  input  to  the 

use-state  and  stacks  the  current  use-state. 

3.  Statement  3  uses  A  as  output  and  Y  as  input  (this 
is  already  described  in  the  use-state  for  the  path 
originating  at  Statement  2). 

4.  Statement  4  pops  the  use-state  and  then  stacks  the 

use-state  of  the  former  path. 

5.  Statement  5  adds  use  of  Y  as  output  to  the  use-state 
for  the  second  path  originating  at  Statement  2. 

6.  Statement  6  pops  the  use-state  stack  and  causes  the  two 
current  use-states  to  be  combined  into  one.  The  com¬ 
bined  use-state  is  use  of  A  as  output  and  input  on  all 
paths,  use  of  X  as  input  on  all  paths,  use  of  Y  as 
input  on  all  paths,  and  as  output  on  some  paths. 

Iterative  constructs  are  processed  once  in  the  same  sequential  manner. 

As  described  earlier,  references  to  functions  or  subroutines  will  have 
known  variable  use  properties  since  the  function  or  subroutine  will 
already  have  been  analyzed.  Vihen  the  analysis  of  a  module  is  complete, 
use  of  local  variables  as  input  on  some  or  ail  paths  Indicates  a  data 
flow  anomaly,  and  use  of  all  global  variables  is  available  to  compare 
with  data  access  assertions  and  to  define  the  use  properties  of  the  module. 
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An  algorithm  to  automatically  perform  data  flow  analysis  in  the 
manner  just  described  has  been  implemented  in  the  Software  Quality 
Laboratory.  The  implementation  of  the  algorithm  distinguishes  three 
types  of  output  useage.  They  are: 

50  output  on  all  paths 

0  output  on  some  paths 

N  not  used  as  output. 

Similarly  three  types  of  input  useage  are  distinguished;  they  are: 

51  input  on  all  paths 

I  input  on  some  paths 

N  not  used  as  input. 

To  allow  for  undefined  externals,  an  additional  unknown  state,  U  ,  is 
distinguished.  Ten  Input/ouptut  states  for  a  given  variable  are  possible: 

1  (N.N) 

2  (SI.N) 

3  (N,SO)  ) 

4  (SI, SO) 

5  (I,N) 

6  (N,0) 

7  (1,0) 

8  (I, SO) 

9  (SI,0) 

10  (U) 

A  local  variable  is  used  before  being  assigned  a  value  if  its  input  state 
is  SI  .  It  may  be  used  before  having  a  value  if  its  input  state  is  I  . 

A  global  variable's  actual  use  is  consistent  with  asserted  input  usage 
only  if  its  input  state  is  SI  or  I  ,  and  consistent  with  asserted 
output  usage  only  if  its  output  state  is  SO  or  0  .  The  use  state  for 
a  path  is  implemented  as  a  2-by-N  array,  where  N  is  the  number  of 
variables  which  have  been  used  or  set.  The  use  of  each  variable  is 
associated  with  its  symbol  table  pointer,  and  the  array  is  ordered  by 
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symbol  table  entry.  A  variable  width  stack  Is  used  to  temporarily  store 
use  states  during  the  data  flow  analysis  of  a  module. 

The  data  flow  analysis  algorithm  can  be  applied  to  unstructured 
programs.  A  graphical  analysis  is  performed  which  represents  unstruc¬ 
tured  programs  in  a  structured  manner.  The  basic  structured  forms  are 
sequential,  parallel,  and  iterative  combinations  of  single-entry,  single¬ 
exit  sequences  of  statements  (Fig.  4.23).  The  graphical  analysis  per¬ 
formed  is  based  on  two  properties  of  the  three  basic  structured  forms. 

Each  of  the  basic  forms  can  be  characterized  as  a  single  entry/single 
exit  subgraph.  Also  the  graph  of  a  structured  program  which  uses  only 
the  basic  forms  is  built  up  of  well-nested  single  entry/single  exit  sub¬ 
graph,  the  complexity  of  the  graph  can  be  reduced  by  replacing  an  identi¬ 
fied  form  with  a  single  edge  which  goes  from  its  single  entry  to  its 
single  exit.  It  is  then  possible  to  repeat  this  pi'ocess  and  identify 
basic  forms  which  previously  were  composed  of  more  complex  structures  than 
the  edges  which  have  been  Inserted.  The  process  terminates  when  the  re¬ 
sulting  graph  consists  of  a  single  edge  from  the  entry  of  the  module  to 
the  exit  from  the  module.  As  the  reductions  are  being  performed,  it  is 
essential  to  maintain  a  data  structure  which  indicates  the  basic  form 
identified  and  the  single  entry/single  e  .it  (SE/SE)  subgraphs  of  which  it 
is  composed.  The  natural  data  structure  for  this  information  is  a  hier¬ 
archy  of  SE/SE  subgraphs.  The  structure  of  this  heirarchy  corresponds 
directly  with  the  well-nested,  indented  representation  of  the  text  as  a 
structured  program. 

The  SE/SE  tree  (the  structured  graphical  representation  of  the 
program)  is  used  to  perform  the  data  flow  analysis  of  both  structured  and 
unstructured  programs.  The  algorithm  Involves  walking  the  SE/SE  tree 
and  computing  the  use  state  for  each  node  In  the  SE/SE  tree  after  the  use 
states  of  its  sub-trees  have  been  computed.  A  description  of  the  data  flow 
analysis  algorithm  is  presented  In  Fig.  4.24. 
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STRUCTURED  FORMS 


STRUCTURED  CODE 


A 

B 


IF  (P)  THEN 
A 

ELSE 

B 

END  IF 


DO  WHILE  (P) 
A 

END  WHILE 


Figure  4.23.  Basic  Structured  Forms 
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Figure  A. 24.  Data  Flow  Analysis  Algorithm 
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Several  limitations  are  inherent  In  the  simplicity  of  the  data 
flow  analysis  technique.  All  structurally  possible  paths  are  Included 
in  the  data  flow  analysis,  even  though  many  of  them  may  not  be  logically 
executable.  Also  arrays  are  treated  as  single  variables.  The  use  of 
individual  array  elements  is  not  distinguished.  The  implementation 
currently  available  in  the  Software  Quality  Laboratory  does  not  attempt 
to  recognize  equlvalenced  variables  during  the  data  flow  analysis.  These 
limitations  can  cause  invalid  error  and  warning  messages  to  be  generated. 
They  do  not  cause  any  data  flow  anomalies  to  go  undetected  however. 
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5  EXECUTION 

Once  the  techniques  described  in  Sec.  U  hii^ve  been  applied  to  show 

\ 

that  many  of  the  costly  semantic  errors  are  not  present,  the  program  is 
ready  for  an  execution  test.  In  the  execution  test,  the  Software  Quality 
Laboratory  provides  facilities  to  show  what  paths  have  been  tested,  what 
paths  have  not  been  tested,  what  assertions  are  false,  what  the  values  of 
the  Input  variables  were  on  module  entry,  and  what  the  values  of  the  out¬ 
put  variable  were  on  module  exit.  These  facilities  may  be  enabled  or 
disabled  by  the  tester. 

5.1  COVERAGE  REPORTS 

The  reports  which  give  information  as  to  how  well  the  software  is 
being  tested  in  terms  of  number  of  tested  paths,  numbers  of  untested  paths, 
and  number  of  times  each  path  was  executed  are  known  as  the  QUICKLOOK 
coverage  reports.  They  can  aid  the  tester  in  devising  additional  test 
cases,  in  discovering  paths  which  cannot  be  executed  due  to  the  range  of 
valid  data,  and  in  pinpointing  areas  of  the  program  in  which  most  of  the 
execution  time  is  spent. 

For  the  QUICKLOOK  coverage  reports,  the  modules  for  which  data  are 
to  be  collected  must  contain  statements  which  are  treated  as  comments  by 
the  preprocessor.  Such  modules  are  said  to  be  instrumented. 

For  IFTRAN  the  comment  statement 
CENTO  name 

where  name  is  the  module  name  is  placed  just  before  the  first  executable 
statement  in  the  program.  The  accompanying  figure.  Fig.  5.1,  shows  the 
modules  SEARCH  and  TRACK  with  these  statements  which  define  the  modules' 
entry  points. 

In  addition,  one  module,  usually  the  first  must  have  the  comment 
statement 

CINST 


107 


Sto  I.EST  sCc^Ct 


1 

2  f-ROSK*!'  StABCH  (U,PUT.ubTpin,TAPE6s0llTP0T,LT£ST,TAPE5sIHPUT) 

}  C1^ST 

R  litTEuLR  X(>i).lLliiTiUUt4lT 

i  REAL  LiSl 

6  CATA  loMT/S/iCUMT/i/ 

7  CEMC  search 

CD  PATH  1  IS  enter  LECK 


REAC  ULMr.ll(X(l)il:lt3l 
krIIe  (OUl.n  <21  (A(I)  tl.-liSI 


10 

emile  (eofiilMti  .Ea.  ui 

11 

1 

• 

IF  (X(l|  .6T.  0) 

12 

2 

• 

.  CALL  TRACk(X) 

13 

2 

• 

.  UIST  s  SLRKFLUATIXdt* 

lA 

1 

• 

ELSE 

n 

a 

« 

.  CIST  s  0.0 

'it 

1 

ENL  IF 

17 

»R1TE  (CLNlTiSI  OIST 

1£ 

1 

P.lmC  (1uMT,1)(X(1),I:1,3> 

IK 

1 

mRiTE  IOLMT<2)(X(l),l>l,3t 

20 

El  C 

aHIlE 

21 

STOP 

22 

1 

FORXaT(313) 

23 

2 

FORAAT  I7h  inputs, 3191 

2A 

3 

FORAAT  IAH  C1STs,I7) 

23 

END 

CC  PATH 

2  IS  eHIlC  COi 

CD  PATH 

A  IS  IF  THLC, 

s 

XI2|*X(2.  * 

XIS)*X(S>)) 

LO  PATH  6  tS  sTuP 


«L0  r.EST  SClRCE  SLBROOUM  TMACK<XI 

1  SOBRCUTINE  TRACR<XI 

2  ir.TEliLK  A(S)<T(S)«1]KIN 

2  LOCKAu  FlAC 

A  LATA  PbA6/.TRWE«/iMIN/9/ 

i  CENTC  iKACn 


A 

IF  (FLAG) 

7 

1 

.  FLAG 

s  .FALSE, 

e 

1 

.  for 

(1  s  1  TO  91 

9 

2 

•  • 

XUI  s  T(lt 

10 

1 

.  LNC 

FCH 

11 

else 

12 

1 

.  IF  « 

1ABS(T(1| 

•  xiin 

.GT.  PIN 

19 

2 

•  9 

FOR  U  «  1 

TO  91 

lA 

9 

•  • 

.  All)  s 

KI» 

19 

2 

•  « 

END  FOR 

IS 

1 

.  ELSE 

17 

2 

•  9 

FCR  (1  *  1 

TO  91 

1» 

9 

9  9 

.  XIII  A 

1X11)  * 

Vlll)/2 

19 

9 

9  9 

.  Kits 

XUI 

20 

2 

9  9 

END  FOR 

21 

1 

,  END 

IF 

22 

LNO  IF 

29 

HCTCRN 

2A 

End 

CC  path  1  Is  INTEh  deck 
CD  PATH  2  IS  IF  ThUt, 

CD  PATH  A  IS  FOR  CC.  S 

CD  PATH  6  IS  IF  THUEi 

CO  PATH  S  IS  FOR  CO,  9 

CD  PATH  10  IS  FOR  CO,  11 


CO  PATH  12  IS  RETURN 


3  IS  RHILE  EXIT 
IS  IF  false 


IS  IF  false 
IS  FOR  EXIT 

IS  IF  FALSE 
IS  FOR  EXIT 
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Figure  5.1.  Instrumented  Modules 


which  turns  on  the  instrumentation  for  the  module  in  which  the  statement 
appears  and  all  subsequent  modules.  Instrumentation  may  be  turned  off 
in  selected  modules  by  use  of  the  statement 

CNOIN 

which  disables  the  data  collection  process  until  another 
CINST 

is  encountered. 

Besides  preparing  the  module  Itself,  a  QUICKLOOK  command  set  is 
used  to  select  reports  which  may  be  presented.  This  command  set  appears 
just  after  the  data  cards.  If  there  is  an  end  of  file  at  the  end  of  the 
data,  it  must  be  read  by  the  module. 

Three  types  of  commands  are  used:  the  module  select  -omnands,  the 
report  select  commands,  and  the  print  command. 

The  module  select  commands  allow  reports  to  be  printed  for  speci¬ 
fied  modules.  The  two  commands  are: 

QUICKLOOK  MODULE  name 
QUICKLOOK  DETAILED  name 

If  the  DETAILED  report  is  desired,  the  DETAILED  command  must  be  used.  The 
DETAILED  report  presents  the  information  In  a  graphical  form  which  is  easy 
to  read. 

While  the  module  select  commands  state  the  module  names  for  which 
data  are  to  be  collected,  the  report  select  commands  select  which  print¬ 
outs  are  to  be  given.  There  are  four  print  options:  SUMMARY,  NOTHIT, 
DETAILED,  and  CUMULATIVE. 


I  II  I  k 


gives  the  following  infornmtion  in  tabular  form  covering  all  the  selected 
modules : 

1.  Test  case  number 

2.  Module  names  an!  number  of  decision-to-declsion  paths 

3.  Number  of  module  invocations,  number  of  decislon-to-decislon 
paths  traversed,  percent  coverage  for  this  test  case 

4.  Total  number  of  module  invocations,  number  of  decision-to- 
decision  paths,  and  percent  coverage  for  all  test  cases. 

Figure  5.2  shows  the  SUMMARY  report  as  a  result  of  executing  the 
modules  SEARCH  and  TRACK  with  the  two  sets  of  input  data  x  =  {5,3,6}  and 
X  -  {7,2,7}  . 

At  this  point  the  tester  might  decide  further  testing  is  necessary 
and  look  at  the  NOTHIT  report  to  see  what  paths  were  not  executed  and 
refer  back  to  the  program  listing  to  see  what  additional  test  cases  could 
cause  the  paths  to  be  executed. 

The  command 

QUICKLOOK  PRINT  NOTHIT 

presents  the  following  report  (next  page)  listing  the  decision-to-decision  path 
numbers  for  each  module  which  were  not  executed.  The  paths  are  listed 
for  each  test  case  and  for  all  test  cases. 

The  tester  might  in  addition  look  at  the  DETAILED  and  CUMULATIVE 
reports  to  see  the  unexecuted  paths  and  note  which  paths  are  executed  the 
most  frequently.  The  DETAILED  report  shows  for  each  test  case  the  number 
of  times  a  decision-to-decision  path  was  executed  in, graphical  form  and 
gives  overall  coverage  data  for  each  module  that  was  selected. 
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NOTHIT  Report 


The  CUMULATIVE  command  presents  the  results  of  several  test  cases 
in  the  same  graphical  format  as  in  the  DETAILED  report.  Figure  5.3  shows 
the  DETAILED  report  for  the  test  of  the  modules  STACK  and  SEARCH.  The 
CUMULATIVE  report  is  the  same  as  the  DETAILED  report  in  this  case. 

These  reports  are  generated  as  a  result  of  the  two  commands: 

QUICKLOOK  PRINT  DETAILED 
QUICKLOOK  PRINT  CUMULATIVE 

The  third  type  of  command  is 
QUICKLOOK 

which  provides  a  listing  of  the  requests  that  were  made  such  as  is  shown 
in  Fig.  5.3  (next  page). 

As  an  example  of  a  QUICKLOOK  command  set  which  produced  all  the 
possible  reports  for  a  set  of  two  modules,  one  of  which  is  the  main 

program  SEARCH  and  the  other  which  is  the  subprogram  TRACK  is:  ^ 

QUICKLOOK  DETAILED  SEARCH 
QUICKLOOK  DETAILED  TRACK 
QUICKLOOK  PRINT  SUMMARY 
QHICKLOOK  PRINT  NOTHIT 
QHICKLOOK  PRINT  DETAILED 
QUICKLOOK  PRINT  CUMULATIVE 
QUICKLOOK 

5.2  ASSERTIONS 

Executable  assertions  may  be  used  during  execution  to  aid  in  testing 
and  to  aid  in  generating  the  correct  assertions  which  can  be  used  in  the 
formal  verification  of  a  program. 

During  the  testing  phase,  executable  assertions  are  valuable  in 
checking  that  interfaces  have  been  specified  correctly.  While  the  static 

) 
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Report  from  Command  QUICKLOOK 


analysis  techniques  described  in  Sec.  4  will  detect  most  of  the  serious 
errors,  there  still  remains  the  possibility  of  data  being  out  of  the 
expected  range  of  values.  This  k :nd  of  error  can  be  detected  by  explicitly 
stating  range  restrictions  on  eveiy  input  variable  in  the  INITIAL  assertion. 
If  an  error  occurs  the  name  of  the  module  and  the  assertion  number  is  re¬ 
ported  on  a  listing.  A  trace  of  toe  values  of  the  input  variable  values 
which  is  given  by  the  INPUT  assertion  should  then  aid  in  the  detection  of 
the  source  of  the  error.  The  fact  that  in  one  module  the  range  of  the 
values  generated  is  not  consistent  with  what  is  expected  by  a  subsequent 
module  will  be  immediately  obvious. 

Thus  if  processing  data  from  a  radar  which  provides  a  beam  number 
between  2  and  1021,  a  range  bln  number  between  80  and  1600,  and  a  signal 
strength  number  between  0  and  95,  one  should  have  in  the  processing 
routine  which  receives  the  data  as  the  first  executable  statements: 

INPUT  ( / INTEGER/ BEAM , RANGE , SIGNAL ) 

INITIAL  (2  .LE.  BEAM  .AND.  BEAM  .LE.  1021) 

*  .AND.  80  .LE.  RANGE  .AND.  RANGE  .LE.  1600 

*  .AND.  0  .LE.  SIGNAL  .AND.  SIGNAL  .LE.  95) 

for  IFTRAN 

INPUT  beam,  range,  signal; 

INITIAL  2  <=  beam  AND  beam  <=  1021 

AND  80  <=  range  AND  range  <=  1600 
AND  0  <=  signal  AND  signal  <=  95; 

for  V-PASCAL. 

Similar  processing  is  available  for  the  output  variables  which  can 
be  checked  for  their  range  of  values.  If  for  the  example  the  radar  data 
described  above  was  transformed  into  a  cartesian  coordinate  system  where 
the  X,Y,Z  coordinates  were  in  terms  of  meters,  and  it  was  known  that  X 
could  be  between  500  and  100,000  meters,  Y  could  be  between  -50,000  and 
40,000  meters,  and  Z  could  be  between  50  and  75,000  meters,  a  reasonable¬ 
ness  check  could  be: 


OUTPUT  (/REAL/X,Y,Z) 

FINAL  (500.0  .LE.  X  .AND.  X  .LE.  100000.0  .AND. 

-50000  .LE.  Y  .AND.  Y  .LE.  40000.0  .AND. 

50.0  .LE.  Z  .AND.  Z  .LE.  75000.0) 

A  better  check  would  be  to  relate  the  outputs:  X,Y  and  Z  to  the  inputs 
such  as  making  use  of  the  relation  between  range  and  the  outputs: 

If 

2  2  2  2 
range  =  X  +  Y  +  Z 

and  if 

radar  range  *  k  =  range  in  meters 
we  could  state 

FINAL  ((RANGE*K)**2  -  (X**2  +  Y**2  +Z**2)  .LE.  RNDOFF) 
for  IFTRAN  and 

FINAL  (range*k)*(range*k)  -  (x*x  +  y*y  +  i*z)  <=  rndoff; 
for  V-PASCAL. 

5.3  FAULT  DETECTION 

Once  a  program  has  been  verified,  it  is  known  that  it  will  produce 
the  specified  results  as  stated  in  the  FINAL  assertion  under  the  condi¬ 
tions  that  are  stated  in  the  INITIAL  assertion.  The  assertions  can  then 
be  used  for  detection  of  faults  due  to  bad  input  data  or  bad  hardware. 

One  of  the  possible  causes  of  catastrophic  failure  in  a  computer 
system  is  bad  input  data.  If  the  data  is  from  a  sensor  that  normally 
provides  more  data  than  is  necessary,  the  bad  value  can  be  discarded  and 
the  system  can  proceed  to  accept  another  value  until  n  bad  values  in  a 
row. 

The  assertions  with  a  FAIL  clause  can  be  used  to  provide  for  fault 
detection  with  a  user-supplied  block  that  can  be  used  for  fault  recovery. 


If,  for  example,  it  was  known  that  the  input  SIGNAL  should  fall  between 
5  and  95,  and  if  SIGNAL  is  invalid  an  error  flag  should  be  set,  the 
following  assertion  could  be  used: 

ERROR  =  .FALSE. 

ASSERT  (SIGNAL  .GE.  5  .AND.  SIGNAL  .LE.  95) 

*  FAIL  (ERROR  FIX) 

IF  (.NOT.  ERROR) 

normal  processing 

END  IF 


BLOCK  (ERROR  FIX) 
ERROR  =  .TRUE. 
END  BLOCK 


In  this  case,  if  the  input  did  not  meet  the  specification,  rather  than  a 
report  on  the  listing  of  a  false  assertion,  the  user-supplied  block  named 
ERROR  FIX  is  Invoked  to  set  the  ERROR  flag. 

In  V-FASCAL,  the  same  assertion  would  be: 
error  :=  false; 

ASSERT  signal  >=  5  AND  signal  <=  95 
FAIL  error  :=  true  END  FAIL; 

IF  NOT  error  THEN 

normal  processing 
END  IF; 


Rather  than  skip  the  processing  the  designer  might  decide  to  set  SIGNAL 
to  a  nominal  value  or  to  an  old  value. 


117 


v«» 


This  could  be  done  by 


ASSERT  (SIGNAL  .GE.  5  .AND.  SIGNAL  .LE.  95) 
FAIL  (ERROR  FIX) 
normal  processing 


BLOCK  (ERROR  FIX) 

SIGNAL  =  NOMINL 
END  BLOCK 

While  the  same  results  could  be  obtained  by  a  series  of  IF  tests  in 
either  language,  the  advantages  of  using  the  assertions  are: 

1.  The  conditions  under  which  the  code  that  follows  is  expected 
to  operate  are  explicitly  stated 

2.  The  methods  of  handling  errors  due  to  input  data  are  separated 
from  the  rest  of  the  code 

3.  The  assertions  used  in  fault  detection  are  the  ones  used  in 
a  formal  verification 


6  FORMAL  VERIFICATION 

A  major  part  of  the  work  is  the  development  of  a  capability  for  the 
verification  of  FORTRAN  and  PASCAL.  This  has  resulted  in  the  design  and 
implementation  of  a  verification  condition  generator,  a  simplifier,  and 
an  interactive  simplifier  which  are  able  to  verify  single  modules. 

6.1  VERIFICATION  TOOLS 

6.1.1  Design  and  Implementation  of  VCG 

The  verification  condition  generator  produces  verification  condi¬ 
tions  for  programs  with  assertions  written  in  FORTRAN,  IFTRAN,  or  the 
subset  of  PASCAI,  limited  to  FORTRAN-like  data  types. 

The  verification  condition  generator  uses  assertions  which  have 
been  inserted  into  the  source  code  to  generate  verification  conditions 
in  the  form  A  -+■  B  ,  where  A  is  the  initial  assertion  on  a  program  path 
conjuncted  with  the  predicates  encountered  along  the  path  and  B  is  the 
assertion  at  the  end  of  the  path.  All  variables  in  the  verification  con¬ 
dition  are  represented  in  terms  of  their  symbolic  value  at  the  start  of 
the  path.  The  required  substitutions  are  made  by  symbolically  executing 
the  final  assertion  and  any  predicates  backwards  to  the  initial  assertion. 

Three  keywords  are  used  to  state  assertions  in  the  present  system. 
These  are  INITIAL,  FINAL,  and  ASSERT.  The  INITIAL  assertion  is  a  state¬ 
ment  of  the  conditions  which  are  true  when  the  module  is  entered.  The 
FINAL  assertion  is  a  statement  of  the  conditions  that  are  true  on  exit 
from  the  module.  The  ASSERT  statement  is  normally  used  to  express  loop  \ 
invariants,  but  may  be  used  anywhere  in  the  body  of  the  module  to  express 
a  condition  that  is  true  at  that  point.  The  syntax  of  the  assertions  is 
discussed  in  Sec.  3.  First  order  predicate  calculus  statements  about 
program  variables  may  be  expressed  in  the  assertions. 

Program  structure  is  used  to  determine  the  set  of  verification 
conditions  to  generate.  A  well-structured,  single-entry,  single-exit 
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program  has  a  readily  identified  set  of  verification  conditions.  There 
is  a  verification  condition  for  each  verification  path  in  the  program. 
Verification  paths  begin  at  the  program  entry  point  and  loop  entry  points, 
and  end  at  the  program  exit  point  and  loop  exit  points.  Each  logically 
possible  path  between  program  entry,  loop  entry,  loop  exit,  and  program 
exit  corresponds  to  a  verification  path.  Each  verification  path  must 
begin  and  end  with  an  INITIAL,  FINAL,  or  ASSERT  statement. 

Specification  of  verification  conditions  is  presently  handled  by 
stating  the  set  of  DD-paths  which  lie  between  assertions.  For  example, 
a  verification  condition  is  generated  by  giving  the  static  analysis 
system  a  command  of  the  form: 

VCG,  PATH  =  2,1,3. 

"VCG"  commands  the  system  to  invoke  the  verification  jcondition 
jg^enerator.  PATH  =  2,1,3  is  an  example  of  the  present  method  of  specify¬ 
ing  the  path  over  which  the  condition  is  to  be  generated.  The  general 
form  of  the  command  is 

VCG, PATH  ■  <no.  of  paths>{,<dd  path  number>} 

In  the  example,  two  decision-to-decision  (dd)  paths  are  specified;  path 
number  1  and  path  number  3.  The  verification  condition  generator  will 
take  the  first  assertion  on  path  1,  the  last  assertion  on  path  3,  and  the 
intervening  body  of  code  to  generate  a  verification  condition. 

The  program  SIMP  is  a  very  simple  IFTRAN  program  which  contains 
three  DD-paths. 

PROGRAM  SIMP  (INPUT,  OUTPUT) 

ENTRY  (.TRUE.) 

A  =  5.0 

B  -  0.0 

WHILE  (A  .GE.  0.0) 

ASSERT  (A  .GE.  0.0  .AND.  B  .LE.  A**(-2)) 

B  -  A**(-2) 
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END  WHILE 

EXIT  (B  .LE.  I.OE-14) 

STOP 

END 

Path  1  covers  the  program  entry  statement  up  to  the  WHILE  statement. 
Path  2  covers  the  "true"  part  of  the  WHILE  statement  and  the  statements 
in  the  loop.  Path  3  covers  the  "false"  part  of  the  WHILE  statement  and 
the  statements  following  the  END  WHILE. 

The  verification  condition  generator,  when  given  the  command 
VCG,  PATH  =  2,1,3  will  take  the  assertion  on  path  1,  ENTRY  (.TRUE,);  the 
statements  A  =  5.0  and  B  =  0.0;  the  "false"  of  WHILE  (A  .GE.  0.0);  and 
the  assertion  on  path  3,  EXIT  (B  .LE.  l.OE-14),  to  generate  the  verifica¬ 
tion  condition: 

(.TRUE.)  A  (5.0  .LE.  0.0)  ->■  (0.0  .LE.  l.OE-14) 

In  this  simple  example,  the  premise  is  false  and  hence  the  resulting 
condition  is  true.  When  the  premise  is  false,  the  implication  is  that  the 
selected  path  combination  is  impossible. 

Although  this  method  of  selecting  verification  conditions  to  be 
generated  provides  flexibility  for  symbolic  execution,  a  more  automatic 
selection  mechanism  which  relates  to  the  assertions  is  under  development. 

Other  approaches  to  verification  condition  generation  are  possible. 
Most  existing  program  proving  systems  generate  one  complicated  verifica¬ 
tion  condition  for  an  entire  program.  The  advantages  of  associating 
verification  conditions  with  verification  paths  are: 

1.  Verification  conditions  are  smaller  and  more  susceptible  to 
automatic  simplification 

2.  Verification  conditions  are  more  readable,  allowing  more 
Intelligent  Interactive  simplification 
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The  size  of  verification  conditions  is  ^ndspendent  of  program 
size 


k.  Incorrect  assertions  or  code  are  easily  found  since  each 

verification  condition  is  associated  with  a  single  verifi¬ 
cation  path. 

A  potential  disadvantage  is  the  large  number  of  verification  condi¬ 
tions  which  may  be  required  for  some  programs.  This  has  not  been  a 
problem  yet. 

Several  automatically  produced  reports  are  related  to  verification 
condition  generation.  Figure  6.1  shows  the  DD-path  definitions  report 
for  program  SIMPLE.  This  report  provides  the  DD-path  numbers  used  in 
specifying  verification  paths.  It  is  produced  with  the  commands: 

MODULE  *  (SIMPLE). 

PRINT,  DDPATHS. 

There  is  one  verification  path  around  the  loop  in  SIMPLE,  it  is  specified 
with  the  command 

VCG.PATH  =■  2,2,2. 
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Figure  6.1.  DD-Path  Definitions  for  Module  SIMPLE 


Figure  6.2  is  produced  as  a  result  of  this  command.  It  Identifies  the 
statements  in  the  specified  verification  path.  This  verification  path 
corresponds  to  going  around  the  loop  in  SIMPLE  once.  Figure  6.3  is  also 
produced  as  a  result  of  the  VCG,PATH  command.  It  is  the  verification 
condition  associated  with  the  verification  path  in  Fig.  6.2.  Each  term 
in  the  verification  condition  is  directly  related  to  the  source  line 
number  from  which  it  was  derived. 
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Figure  6.2.  Verification  Path  Report  for  Module  SIMPLE 


line  VEKIFICAtIUA  CCNCIlION 

5  A  .GE.  0 

AND 

6  A  (GC*  0*0  •Ai«0*  d  tLE.  A  •  2 

AND 
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Figu’^rt  6.3.  Verification  Condition  Report  for  Module  SIMPLE 


All  variables  In  the  verification  condition  are  represented  in 
terms  of  their  symbolic  value  at  the  start  of  the  verification  path.  The 
verification  condition  is  constructed  as  the  verification  path  Is  symbol¬ 
ically  executed  in  reverse  order.  Each  statement  type  encountered  when 
traversing  the  verification  path  in  reverse  order  affects  the  verification 
condition  being  generated.  The  rules  for  FORTRAN  are: 

•  When  a  decision  statement  or  assertion  is  encountered,  the 
appropriate  condition  is  added  as  an  .AND.  term  to  the 
current  formula  (the  final  assertion  is  added  as  the  conse¬ 
quence  of  the  .IMP.)* 

•  An  assignment  statement  of  the  form  x  =  y  causes  all 
instances  of  the  term  x  to  be  replaced  with  y  in  the 
current  formula. 

•  An  iteration  control  statement,  such  as  the  statement  at  the 
end  of  a  FORTRAN  DO-loop,  causes  all  instances  of  the  itera¬ 
tion  index  to  be  replaced  with  the  incremented  value.  This 
is  an  assignment  statement  of  the  form:  <index>  =  <index> 

+  <increment>. 

•  An  iteration  initiation  statement,  such  as  a  FORTRAN  DO- 
statement,  causes  replacement  of  instances  of  the  <index> 
with  its  <initial-value> . 

•  A  statement  label  assignment  results  in  replacement  of 
instances  of  the  label-name  with  the  actual  label. 

Planned  extensions  to  the  verification  condition  generator  will  allow 
subroutine,  function,  and  READ  statements  to  be  symbolically  executed 
when  the  corresponding  subroutine,  function,  or  I/O  unit  has  been  defined 
using  INITIAL,  ASSERT,  and  FINAL  statements. 

6.1.2  Simplifier  Design  and  Implementation 

The  verification  condition  simplifier  consists  of  two  separate 
parts:  a  standard  simplifier  and  a  user  supplied  simplifier.  The 
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standard  simplifier  applies  a  small  set  of  arithmetic,  logical,  and 
relational  simplifications  in  an  attempt  to  reduce  the  verification 
condition  to  "true."  The  result  of  this  attempt  is  presented  to  the 
user  who  can  then  supply  additional  simplification  rules,  which  are 
peculiar  to  the  problem  at  hand.  Once  a  new  rule  has  been  applied,  the 
modified  result  is  sent  through  the  simplifier  again  and  the  new  result 
is  presented  to  the  user.  In  this  manner,  the  user  can  verify  the  pro¬ 
grams  that  the  standard  simplifier  cannot. 

6. 1.2.1  Standard  Simplification 

The  simplifier  first  puts  the  verification  condition  into  a  tree 
data  structure.  The  root  of  the  tree  contains  the  Implies  operation.  In 
Fig.  6.4,  the  tree  for  the  expression 

A>2->A>2vA=2 

is  shown  as  it  is  seen  by  the  simplifier.  A  small  set  of  tree  operations 
were  defined  so  that  it  was  not  difficult  in  IFTRAN  to  build  trees,  walk 
trees,  delete  nodes,  move  nodes,  or  print  trees  in  the  form  shown  in  the 
figure. 

Once  the  tree  has  been  formed,  a  lexical  level  is  assigned  to  each 
leaf  so  that  a  lexical  ordering  of  the  nodes  can  be  performed.  This 
allows  the  simplifier  to  recognize  that  the  expressions 

A  +  B  +  C 
A  +  C  +  B 
B  +  A  +  C 
B  +  C  +  A 
C  +  A  +  B 
C  +  B  +  A 

are  all  the  same.  The  lexical  ordering  would  result  in  the  preceding 
expression  being  replaced  by 

A  +  B  +  C 
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Figure  6.4.  Simplifier  Tree 

Constants  have  the  lowest  lexical  order  so  any  one  of  the  expressions 

A  +  1  +  B 
1  +  A  +  B 
B  +  1  +  A 
B  +  A  +  1 
1  +  B  +  A 
A  +  B  +  1 

would  be  replaced  by 
1  +  A  +  B 

Lexical  ordering  is  part  of  the  normalization  process  which  takes 
place  before  the  actual  simplification  takes  place.  Normalization  is 
divided  into  four  parts: 

1.  Products  normalization 

2.  Conjunctive  normalization 


3. 

4. 


Relation  normalization 
Lexical  normalization 


Products  normalization  places  expressions  in  a  sum  of  products  form. 
That  is  if  the  expression  is 

A  *  (B  -  C) 

it  will  be  normalized  to 
A  *  B  -  A  *  C 


Products  normalization  also  moves  negations  inwards  to  the  indivi¬ 


dual  terms  that  are  being  operated 
Some  examples  are; 

Original 

A  -  (A  +  B) 

A  -  (-A  +  B) 

-(-(A)) 

Conjunctive  normalization  is 
The  logical  expressions  are  placed 
side  of  the  implies. 

Original 

(A  A  B)  V  c 

(A  A  B)  V  C  (A  A  D)  V  C 


on.  Double  negations  are  removed. 

Normalized 
A  -  A  +  B 
A  +  A  +  B 
A 

similar  to  products  normalization, 
in  conjunctive  normal  form  on  each 

Normalized 

(A  V  C)  A  (B  V  C) 

(A  V  C)  A  (B  V  C)  ->■  (A  V  C)  A  (D  V  C) 


Conjunctive  normalization  is  not  applied  across  the  Implies  because 
it  is  expected  that  human  interaction  will  operate  better  when  the  veri¬ 
fication  condition  simplifications  are  recognizable,  when  the  clauses 
remain  tied  to  the  code  and  the  assertions,  and  when  the  assertion  on  the 
right  hand  side  of  the  implies  is  kept  as  a  separate  set  of  clauses.  This 


is  considered  particularly  important  when  a  user  attempts  to  generate  a 
loop  invariant  from  the  verification  condition  as  described  in  Sec.  6.1.3. 


Just  as  products  normalization  brings  in  the  negation  operation 
next  to  individual  terms,  conjunctive  normalization  brings  in  the  NOT 
operation  next  to  individual  terms.  Double  NOTs  are  removed. 


Original 

llA 

1(A  V  B) 
1(A  A  iB) 


Normalized 

A 

lA  A  IB 
1  A  V  B 


Relational  operators,  the  divide  operator,  and  the  exponential 
operator  pose  special  problems.  This  simplifier  leaves  the  division 
operator  and  the  exponential  operator  as  they  appear  in  the  original 
expression.  Normalization  across  the  relational  operators  takes  place 
so  that  the  normal  form  is 

<variable  expression>  <relation>  <constant> 

Examples  are: 

Original  Normalized 

A>B  A-B>0 

3  <  C  C  <  3 

A+2>D+7  A-D>7-2 

After  a  verification  condition  has  been  placed  in  normal  form,  it 
is  simplified.  The  simplifier  consists  of  five  parts  which  are  applied 
sequentially  to  each  subtree  during  a  post  order  walk  of  the  tree.  The 
five  parts  are: 

1.  Constant  simpHf Ication 

2.  Common  term  simplification 
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3.  Logical  simplification 

4.  Cancellation 

5.  Relational  simplification 

It  is  assumed  that  the  normalization  process  will  have  brought 
constant  terms  together.  The  constant  simplification  process  will  then 
evaluate  arithmetic  f.nd  logical  expressions  which  contain  constants. 
Special  rules  for  0  and  1  are  Incorporated  in  the  constant  simplification 
process.  Constant  expressions  which  are  simplified  may  be  real.  Integer, 
or  logical  data  types.  Examples  of  constant  simplification  are: 


Original 

Simplified 

A  >  3  +  6 

A  >  9 

.TRUE.  -*■  INPUT3  >  0 

INPUT3  >  0 

.FALSE.  ■>  INPUT2  <  0 

.TRUE. 

B  <  6  ->  .FALSE. 

B  ^  6 

1  *  RANGE  +  6 

RANGE  +  6 

0/TIME 

0 

0  +  DIST 

DIST 

1  **  FINALV 

1 

.TRUE.  A  (C  >  6) 

C  >  6 

1  +  2 

3 

6.0  +  3.0 

9.0 

2  <  7 

.TRUE. 

.TRUE.  V  (F  >=  MA) 

.TRUE. 
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Common  term  simplification  searches  arithmetic  expressions  for  equal 
terms  which  can  be  combined  into  a  similar  expression. 


Original 


Simplified 


A  -  A  +  B 


B 


A  *  B  -  A  *  B 


0 


A  *  B  +  A  *  B 


2  *  A  *  B 


Logical  simplification  does  the  same  as  common  term  simplification 
for  the  logical  operators. 

Original  Simplified 

(A  +  B  >  5)  A  (A  +  B  >  5)  (A  +  B  >  5) 

(C  <  E)  V  (C  <  E)  (C  <  E) 

Cancellation  of  like  terms  across  the  implies  is  a  separate  part  of 
the  simplification  process.  If  a  clause  on  the  right  part  of  the  implies 
is  the  same  as  a  clause  on  the  left  hand  side,  the  right  hand  clause  is 
replaced  by  .TRUE..  The  goal  of  the  simplification  process  is  to  delete 
as  many  clauses  as  possible  so  that  eventually  the  verification  condition 
appears  as: 

Cj^  A  C2  A  . . .  A  C^  .TRUE. 

which  is  simplified  to  .TRUE..  Examples  of  cancellation  are: 

Original  Expression 

(A  >  5)  A  SORTED  a  (L  <  N)  SORTED 

Simplified  Expression 
.TRUE. 
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Original  Expression 

(RANGE  >  0)  A  (ELEVATION  >  50)  (RANGE  >  0)  a  (AZIMUTH  >  3) 
Simplified  Expression 

(RANGE  >  0)  A  (ELEVATION  >  50)  (AZIMUTH  >  3) 


Relational  simplification  takes  conjuncted  relations  which  involve 
equivalent  terms  and  replaces  them  with  the  stronger  relation. 


Original 

(RANGE  >  3)  A  (RANGE  >  5) 
(TIME  S  6)  A  (TIME  >  6) 
(DIST  >  3)  A  (DIST  <  2) 
(SPEED  i  0)  v  (SPEED  <  0) 
(VEL  S  2)  A  (VEL  2) 


Simplified 
(RANGE  >  5) 
(TIME  >  6) 
.FALSE. 
.TRUE. 

(VEL  *  2) 


If  as  a  result  of  simplification  a  variable  Is  equal  to  a  constant, 
that  constant  replaces  the  variable  in  other  clauses  and  the  result  is 
resiraplified 

Original 

(B  S:  0)  A  (B  ^  0)  1  =  A**B 

Simplified 

(B  =  0)  ->  1  *  A**B 

Reslmpllf led 
.TRUE. 


6. 1.2. 2  User-Supplied  Simplifications 

Although  the  standard  simplifier  contains  many  rules,  it  cannot 
automatically  verify  all  the  verification  conditions  from  many  programs. 
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Rather  than  change  the  simplifier  or  develop  a  complete  theorem  prover, 
the  capability  for  adding  rules  to  the  simplification  process  was  provided. 

Two  forms  of  rules  are  available.  The  first  uses  simple  text  re¬ 
placement  and  the  second  uses  pattern  matching.  Under  text  replacement, 
if  a  verification  condition  contained  an  expression  of  the  form 

B  S  0 

and  the  user  desired  to  change  this  to 
B  >  0  V  B  =  0 


the  command  sequence  would  be 
VCG, REPLACE. 

B  .GE.  0  =  B  .GT.  0  .OR.  B  .EQ.  0 
*END. 

for  IFTRAN  OR 

VCG, REPLACE. 

B>-0  =  B>OORB  =  O 
*END. 

for  V-PASCAL. 

Such  a  command  will  cause  the  verification  condition  to  be  searched 
for  the  text  string  B  S  0  which  will  be  replaced  with  the  text  string 
B  >  0  V  B  ■  0.  Then  the  standard  simplifier  will  be  reinvoked  to  see  if 
the  modified  verification  can  be  reduced  to  .TRUE,  by  the  standard 
simplifier. 

The  replacement  operation  is  implemented  by  the  formation  of  a  tree 
with  the  replacement  equality  operator  as  the  root.  The  verification 
condition  is  searched  for  subtrees  which  are  equal  to  the  left  subtree  of 
the  replacement  tree.  If  found  the  right  subtree  is  used  for  the  replace¬ 
ments. 
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The  more  general  method  is  to  use  pattern  replacement  rather  than 
text  strings  which  require  exact  matches.  Pattern  replacements  are  done 
with  special  pattern  variables: 

PX1,PX2 . PXIO. 

An  example  of  a  pattern  variable  rule  is: 

PXl  >  PX2  A  PX2  >  PX3  =  PXl  >  PX3 


If  this  were  applied  to  a  verification  condition  which  was 

(RANGE  >  MINRANGE)  a  (MINRANGE  >  INPUT2)  (RANGE  >  INPUT2) 

PXl  would  match  RANGE 
PX2  would  match  MINRANGE 
PX3  would  match  INPUT2 

so  the  replacement  would  result  in 

RANGE  >  INPUT2  RANGE  >  INPUT2 

which  the  simplifier  would  recognize  as  being  .TRUE.. 

Pattern  replacement  rules  are  entered  in  the  same  manner  as  text 
replacement  rules. 

The  preceding  rule  would  be  entered  as 
VCG, REPLACE. 

PXl  .GE.  PX2  .AND.  PX2  .GT.  PX3  =  PXl  .GT.  PX3 
*END. 


for  IFTRAN,  or  as 

VCG, REPLACE. 

PXl  >"  PX2  AND  PX2  >  PX3  -  PXl  >  PX3 
*END. 

for  V-PASCAL. 
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By  the  combination  of  using  the  standard  simplifier  and  the  user 
supplied  simplifier,  several  small  programs  have  been  formally  verified 
as  described  in  Sec.  6.3.  In  the  process  of  verifying  the  programs,  it 
was  discovered  that  once  a  new  rule  was  defined  to  verify  part  of  a  pro¬ 
gram,  it  was  used  repeatedly  in  the  verification  of  that  program.  In 
order  to  save  the  effort  of  re-entering  rules,  the  AXIOM  command  was 
implemented.  Instead  of  giving  the  command  sequence 

VCG,REFLArE,. 

<rule> 

*END. 

one  states 

VCG.AXiOM. 

<rule> 

*END. 

The  rule  will  be  assigned  an  axiom  number  and  saved  on  a  library  of  rules. 

A  rule  which  does  not  result  in  any  replacements  will  not  be  saved.  Once 
on  the  library,  the  user  need  only  refer  to  the  axiom  number  as  for 
example, 

VCG.AXIOM, 1. 

VCG,AXI0M,3. 

which  would  cause  axiom  1  to  be  applied  and  then  axiom  3. 

6.1.3  Adding  Assertions  Using  Verification  Conditions 

22 

One  of  the  methods  proposed  by  Webgreit  to  synthesize  loop  invari¬ 
ants  uses  the  FINAL  assertion  and  the  exit  condition  from  the  loop.  The 
trail  loop  invariant  which  is  formed  is  then  modified  using  a  set  of  heur¬ 
istics  until  it  satisfies  the  conditions  of  a  loop  invariant.  The  Soft¬ 
ware  Quality  Laboratory  provides  a  means  whereby  trail  assertions  may  be 
placed  in  a  program.  The  verification  conditions  which  are  generated  from 
the  trail  assertions  may  be  examined  to  see  how  to  alter  the  assertion  so 
that  the  verification  conditions  are  valid. 


■  /I  ■  rv 
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By  way  of  example,  the  text  of  the  DIV  subroutine  which  corresponds 
to  Wegbreit's  first  example  is  used  as  shown  in  Fig.  6.5.  Assuming  that 
the  INITIAL  and  FINAL  assertions  are  provided,  the  problem  is  to  find  the 
loop  invariant  which  is  placed  in  an  ASSERT  statement.  The  ASSERT  state¬ 
ment  is  expected  to  satisfy  the  following  verification  conditions  for  the 
loop: 

1.  Loop  entry 

INITIAL  A  (loop  entry)'  ASSERT' 

2.  Around  the  loop 

ASSERT  A  (loop  continue)'  ASSERT' 

3.  Loop  exit 

ASSERT  A  (loop  exit)'  FINAL' 

where 

loop  entry  is  the  condition  or  predicate  that  causes  entry 
to  the  loop 

loop  continue  is  the  condition  under  which  control  remains 
in  the  loop 

loop  exit  is  the  condition  that  causes  transfer  out  of  the 
loop 

and  INITIAL,  ASSERT,  and  FINAL  refer  to  the  logical  expressions 
in  the  assertions. 

The  primed  terms  refer  to  the  logical  expressions  as  they  appear  in 
terms  of  the  variables  that  exist  at  the  start  of  the  loop. 

For  the  example  shown, 

INITIAL  -AaOABSO 
FINAL  -  A-  Q*B  +  RaO£RaR<B 
loop  entry  *  loop  continue  =  R  i  B 
loop  exit  *  R  <  B 
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Figure  6.5.  DIV  Subroutine  with  Trail  Loop  Invariant 


Wegbrelt  states  that  the  standard  means  for  generating  a  loop  invariant 
is  to  start  with  the  loop  exit  verification  condition  and  use  a  trail 
verification  condition 

(loop  exit)'  -*■  FINAL' 

In  the  Software  Quality  Laboratory,  a  trail  loop  invariant  can  be 
generated  by  setting  the  loop  invariant  to  .TRUE,  as  shown  in  the  text  of 
the  program.  A  verification  condition  is  then  generated  for  the  path 
around  the  loop.  The  resulting  verification  condition  is  then  placed  in 
disjunctive  form  by  using  the  REPLACE  command  with  the  rule 

PXl  .IMP.  PX2  =  .NOT.  PXl  .OR.  PX2 

to  remove  the  implies.  The  result  of  this  operation  is  a  trail  loop 
invariant  which  is  shown  below  the  text  of  the  program. 

Now  the  three  verification  conditions  are  regenerated  using  the 
trail  loop  invariant.  It  is  seen  that  the  second  verification  condition 
cannot  be  reduced  to  true  (see  Fig.  6.6).  One  of  the  heuristics  is  to 
strengthen  the  assertion  by  changing  the  disjunction  to  a  conjunction 
which  v/ill  allow  the  second  verification  condition  to  be  valid.  When 
this  is  done,  all  the  paths  in  the  program  can  be  verified  using  the 
standard  simplifier  as  shown  in  the  second  verified  program  in  Appendix  D. 

6.2  INTERACTIVE  ASSISTANCE 

An  Interactive  interface  to  the  Software  Quality  Laboratory  has  been 

Implemented  to  aid  the  user  in  the  development  of  assertions  and  improve 

tlfe  performance  of  the  simplifier.  Through  the  interface,  the  Software 

Quality  Laboratory  user  can  enter  commands  and  receive  output  through  the 
20 

Anagraph.  A  functional  description  of  the  relationship  between  the  user 
and  the  Software  Quality  Laboratory  is  shown  in  Fig.  6.7. 

Through  the  Anagraph  terminal,  the  user  can  request  verification 
conditions,  provide  trial  assertions,  specify  additional  simplification 
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•  USE  PROGRAH  STRUCTURE  TO  SIMPLIFY  PROOF  STEPS 


•  RELATE  VERIFICATION  CONDITIONS  TO  ORIGINAL  PROGRAM 


Figure  6.7.  Interactive  Program  Proving 


rules,  and  request  the  symbo’ic  execution  of  expressions.  In  response, 
the  Software  Quality  Laboratory  generates  verification  conditions  from 
assertions  in  the  source  code  or  assertions  entered  from  the  Anagraph, 
simplifies  these  verification  conditions,  symbolically  executes  arbitrary 
expressions  over  specified  program  paths,  validates  simplification  rules, 
and  applies  them  to  verification  conditions. 

The  reason  for  Implementing  the  Interactive  simplification  capability 

'  ^ 
is  to  overcome  a  problem  recognized  by  Deutsch: 

There  are  two  respects  in  which  PIVOT  has  failed  to  attain 
the  goals  set  for  it  by  the  author.  One  is  stability. 

Even  though  PIVOT  is  restricted  to  a  fairly  limited  domain, 
each  new  test  case  has  required  adding  simplification  rules 
or  extending  the  logic  of  PIVOT  in  some  way. 

It  is  impractical  to  extend  the  capability  of  a  simplifier  to  prove  every 
possible  program  by  including  every  possible  simplification  rule.  It  is 
more  feasible  to  allow  a  user  to  add  a  rule  that  applies  only  to  a  single 
program. 
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The  reason  for  giving  the  user  the  capability  to  interactively 
specify  assertions  and  generate  verification  conditions  is  to  assist  the 
synthesis  of  loop  invariants.  Untii  loop  invariants  can  be  generated 
automatically,  the  user  will  need  to  supply  these  assertions.  Since  the 
specification  of  loop  invariants  is  an  iterative  process  of  trial  and 
error,  the  user  can  request  that  a  loop  invariant  be  tested  by  symbolic 
execution  through  the  loop. 

The  interactive  interface  was  designed  and  built  at  GRC  Santa  Barbara 
using  a  program  which  simulated  the  action  of  the  Anagraph.  The  Anagraph 
simulation  runs  in  batch  mode  on  the  7600  and  produces  printed  output 
which  is  the  same  as  would  be  seen  on  the  Anagraph  screen.  The  use  of 
the  simulation  greatly  reduced  the  amount  of  time  required  *"0  develop  the 
interactive  interface  and  allowed  all  but  final  testing  to  be  done  in 
batch  mode  from  Santa  Barbara. 

When  the  verification  condition  generator  and  the  simplifier  of  the 
Software  Quality  Laboratory  are  used  interactively  from  the  Anagraph 
terminal,  commands  are  selected  by  the  trackball  and  textual  information 
is  entered  through  the  keyboard.  Some  commands  may  be  entered  by  using 
the  trackball  alone  while  others  (PATH,  REPLACE,  EXPRESSION,  AND  RXVP)^^ 
require  the  user  to  enter  a  text  string  through  the  keyboard.  The  inter¬ 
active  interface  synthesizes  the  command  corresponding  to  the  command 
selected  and  places  it  in  a  command  buffer  which  is  displayed  to  the  user 
when  the  ENTER  button  is  depressed.  The  actual  processing  associated  with 
the  command  takes  place  when  the  command  GO  is  selected  by  the  user. 

Textual  output  generated  by  a  Software  Quality  Laboratory  processing 
module  is  displayed  on  the  Anagraph  screen.  As  each  page  of  output  is 
displayed,  the  user  can  direct  the  interactive  interface  to  display  the 
next  page  of  output,  or  to  cease  displaying  the  output  and  return  to  a 
mode  where  commands  can  be  entered. 

The  figures  in  this  section  were  derived  from  the  Anagraph 
simulator. 


140 


The  basic  display  is  a  menu  of  commands  from  which  the  user  selects 
a  command  by  placing  the  trackball  position  cursor  over  the  command  on 
the  screen  and  pressing  the  trackball  ENTER  key.  The  command  menu  is 
shown  in  Fig.  6.8.  Commands  selected  are  echoed  under  the  heading 
SELECTED  COMMj^NDS.  The  seven  "'ommands  that  can  be  entered  are  described 
in  the  following  paragraphs. 

To  select  the  SIMPLIFY  command,  the  user  places  the  trackball 
cursor  over  SIMPLIFY  on  the  screen,  and  presses  the  trackball  ENTER  key. 
The  command  VCG, SIMPLIFY  is  constructed  and  echoed  on  the  right  half  of 
the  screen,  under  the  heading  SELECTED  COMMANDS  as  shown  in  Fig.  6.9. 

When  the  user  selects  the  PATH  command  using  the  trackball,  the 
interactive  Interface  responds  by  printing  the  prompt  ENTER  PATH  on  the 
screen  below  the  command  menu.  The  user  then  enters  the  number  of  paths 
and  path  list  (such  as  2,1,2)  through  the  Anagraph  keyboard.  At  this 
point  the  screen  appears  as  in  Fig.  6.10.  The  command  VCG, PATH  *  number 
of  paths,  path  list  is  then  constructed  and  entered  in  the  command  buffer 
by  the  interactive  Interface  and  echoed  on  the  right  half  of  the  screen. 

The  PATH  command  causes  the  selection  of  a  report  showing  the  "path 
to  verify,"  as  shown  in  Fig.  6.11.  This  report  replaces  the  menu  display 
on  the  Anagraph  screen. 

When  the  user  selects  the  REPLACE  command  using  the  trackball,  the 
Interactive  interface  responds  by  printing  the  prompt  ENTER  REPLACEMENT 
STRING  on  the  screen  below  the  command  menu.  The  user  then  enters  the 
replacement  string  through  the  keyboard.  The  Interactive  Interface  then 
constructs  the  commands: 

VCG, REPLACE 
replacement  string 
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enters  them  in  the  r.ommand  buffer,  and  echoes  them  on  the  right  half  of 
the  screen. 

The  REPLACE  command  causes  the  generation  of  a  report  showing  the 
result  of  applying  the  simplification  rule  to  the  verification  condition 
being  simplified.  This  report  replaces  the  menu  display  on  the  Anagraph 
screen. 

When  the  user  selects  the  EXPRESSION  command,  using  the  trackball, 
the  interactive  Interface  responds  by  printing  the  prompt  ENTER  EXPRESSION 
on  the  screen  below  the  command  menu.  The  user  then  enters  the  expression 
through  the  keyboard.  The  interactive  interface  then  constructs  the 
commands 

VCG, EXPRESS ION 

expression 

*END. 

enters  them  in  the  command  buffer,  and  echoes  them  on  the  right  half  of 
the  screen. 

The  RXVP  command  is  used  to  enter  commands  to  the  Software  Quality 
Laboratory  which  do  not  appear  on  the  command  menu.  When  the  user  selects 
it,  using  the  trackball,  the  Interactive  interface  responds  by  printing 
the  prompt  ENTER  COMMAND  on  the  screen  belcw  the  command  menu.  The  user 
then  enters  the  command  through  the  keyboard.  The  interactive  interface 
enters  the  command  into  the  command  buffer  and  echoes  it  on  the  right  half 
of  the  screen.  Any  valid  Software  Quality  Laboratory  command  may  be 
entered  in  this  fashion. 

The  reports  corresponding  to  the  entered  command  are  produced  on 
the  Anagraph  screen. 
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The  END  command  Is  used  to  close  all  files,  print  a  final  report, 
and  terminate  the  execution  of  the  Software  Quality  Laboratory.  When  the 
user  selects  it,  using  the  trackball,  the  interactive  interface  places 
the  command  in  the  command  buffer  and  echoes  it  on  the  right  half  of  the 
screen. 

The  END  command  causes  the  generation  of  a  wrapup  report,  which 
lists  the  modules  on  the  library  and  their  attributes,  along  with  statis¬ 
tics  on  library  creation  and  access. 

The  GO  command  causes  the  interactive  interface  to  transfer  control 
to  the  Software  Quality  Laboratory's  command-processing  module.  All  com¬ 
mands  that  have  been  previously  selected  (and  echoed  on  the  screen  under 
SELECTED  COMMANDS)  will  then  be  executed,  and  the  first  page  of  the  re¬ 
sulting  reports  will  be  displayed  on  the  Anagraph  screen. 

As  each  screenful  of  Quality  Laboratory  output  is  displayed  on  the 
Anagraph,  the  user  is  given  the  option  of  viewing  the  next  page  of  output 
or  returning  to  the  command  menu.  These  options  are  pres>inted  to  the 
user  by  the  words  NEXT  PAGE  and  MENU  at  the  bottom  of  the  screen.  To 
select  the  next  page  of  output  or  return  to  the  command  menu,  the  user 
places  the  trackball  cursor  over  the  appropriate  command  and  presses  the 
trackball  ENTER  key.  If  NEXT  PAGE  is  selected  and  there  is  no  more  out¬ 
put,  the  command  menu  is  displayed. 

6.3  VERIFIED  PROGRAMS 

The  formal  verification  process  has  evolved  from  the  generation  of 
verification  conditions  which  required  manual  simplification  to  a  process 
which  requires  human  interaction. 

Included  in  Appendix  D  are  listings  of  programs  for  which  verifi¬ 
cation  conditions  have  been  generated.  Also  included  in  a  few  cases  are 
the  simplified  verification  conditions  and  the  reduction  via  the  user- 
supplied  simplification. 


These  Initial  programs  were  chosen  so  that  comparisons  could  be 

made  between  the  verification  conditions  that  were  generated  by  the 

Software  Quality  Laboratory  and  similar  verification  conditions  generated 
5-9 

by  others.  It  is  recognized  that  others  have  attempted  to  have  their 
conditions  automatically  reduced  to  .TRUE.,  whereas  our  approach  attempts 
to  present  them  to  a  user  in  readable  form  so  that  the  user  can  modify 
them.  This  may  be  why  the  output  shown  in  the  appendix  is  more  readable. 

The  first  nine  programs  are  from  King.^  They  were  also  used  by 
Deutsch^  and  a  few  by  Elspas.^  The  tenth  program  has  been  used  by  Elspas. 
The  eleventh  program  has  been  used  by  several  others. The  twelfth 
program  is  new. 

1.  Program  TIMES  computes  an  output  X  *  A  *  B  by  adding  the  input 
A  to  a  local  variable  SUM,  B  times.  The  local  variable  Y  is 
used  as  a  counter  which  is  initially  set  to  B  and  then  decremented 
to  zero. 

2.  Program  DIV  computes  two  outputs:  Q,  which  is  the  quotient  of  the 
integer  division  of  A  by  B,  and  R,  which  is  the  remainder  of  that 
division.  A  and  B  are  Inputs. 

3.  Program  EXPON  computes  an  output  Z  >•  A  B  by  multiplying  the 
partial  result  times  itself  using  the  binary  value  of  the  input  B 
as  found  by  the  MOD  function.  The  local  variable  X  is  used  as  the 
partial  result  and  Y  is  used  to  find  the  binary  representation  for 
B. 

4.  Program  PRIME  computes  whether  the  input  variable  A  is  a  prime 
number  and  sets  the  output  J  to  a  "0"  if  A  is  prime  of  a  "1"  if 
A  is  not  prime.  Testing  is  done  by  taking  the  remainder  of  A 
divided  by  2  to  A  -  1  using  the  local  counter  I. 

5.  Program  ZERO  sets  an  array  A  of  length  N  to  zero.  A  is  treated 
as  input  and  output.  N  is  input.  The  local  variable  I  is  used 
as  a  counter. 
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Program  MAXI  searches  an  array  A  of  length  N  for  the  largest  element. 
This  element  with  the  largest  value  in  the  array  is  then  swapped 
with  the  element  A(N).  A  is  treated  as  input  and  output.  N  is  input. 
The  local  variable  I  is  used  as  a  counter  and  the  local  variable 
TEMP  is  used  as  temporary  storage  during  the  swap. 

7.  Program  SORTl  performs  a  sort  of  an  array  A  of  length  N.  Elements 
are  exchanged  using  the  local  variable  TEMP.  I  is  a  local  variable 
used  as  a  counter.  J  is  a  local  variable  which  when  set  to  1  indi¬ 
cates  a  swap  was  made.  J  is  0  when  sorting  is  no  longer  necessary. 

A  is  used  as  input  and  output.  N  is  used  as  input. 

8.  Program  MULT2  is  a  more  complex  version  of  the  TIMES  program  which 
performs  multiplication  of  A  times  B  whether  A  or  B  is  negative. 

The  result  is  placed  in  MS  which  is  an  output  variable.  A  and  B 
are  input  variables.  TEMPA,  TEMPB  and  TANS  are  used  as  temporary 
variables. 

9.  Program  S0RT2  also  performs  a  sort  of  the  array  A  of  length  N. 

The  sort  is  accomplished  by  finding  the  largest  element  in  the 
rest  of  array  at  each  iteration.  Local  variables  I,  J  and  K  are 
used  as  counters.  Local  variables  M,  N  and  L  are  used  as  assertion 
counters.  Local  variable  TEMP  is  used  for  swapping.  A  is  used  as 
input  and  output.  N  is  used  as  input. 

10.  Program  BINSCH  performs  a  binary  search  of  an  array  ARRAY  of  length 
LENGTH  for  the  value  in  X.  The  element  index  where  X  is  located 
is  placed  in  the  output  variable  LOOKUP.  If  not  found  the  output 
variable  ERROR  is  set  to  .TRUE.,  otherwise  it  is  set  to  .FALSE.. 

ARRAY,  X,  and  LENGTH  are  treated  as  input  variables.  I  is  a  local 
variable  used  as  a  counter.  M  and  N  are  local  variables  used 

to  delimit  the  area  to  be  searched  each  time.  SORTED  is  a  function 
of  an  assertion  on  the  array,  used  to  provide  a  more  readable 
version  of  the  assumption  that  the  array  is  SORTED  on  input. 
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Program  FIND  is  an  efficient  sorting  algorithm  published  by  Hoare. 

In  this  version  A  is  the  array  of  length  NN  which  is  sorted  about 
element  A(F) .  A  is  used  as  input  and  output.  NN  and  F  are  used 
as  input.  I,  J,  M,  N  are  used  as  counters  in  the  algorithm.  P  and 
Q  are  used  as  counters  in  the  assertions.  PSORT  is  an  assertion 
function  used  to  provide  a  more  readable  version  of  the  assertion 
that  the  array  is  partially  sorted. 

Program  SQX  is  a  square  root  algorithm  using  Newton's  method  to 
find  an  approximation  to  the  square  root  of  the  floating  point  input 
variable  X  .  The  program  is  a  function  where  Y  is  used  as  a 
local  variable  to  represent  the  approximation. 


7  SOFTWARE  DEVELOPMENT  SYSTEM  QUALITY  ASSESSMENT 

In  this  section  we  shall  examine  the  role  of  high-level  languages 

in  the  production  of  reliable  HMD  software.  Our  approach  is  to  use  a 

language  developed  for  multi-tasking  software  systems,  Concurrent 
25 

PASCAL,  in  reprogramming  an  existing  BMD  software  simulation.  The  BMD 
simulation,  GSIM,  has  been  described  in  previous  reports. As  each 
algorithm  from  GSIM  is  implemented  in  Concurrent  PASCAL,  assertions  will 
be  derived  which  express  the  correct  behavior  of  the  algorithm.  From 
these  assertions  we  will  derive  verification  conditions,  simplify  them, 
and  prove  them  correct. 

7.1  THE  APPLICABILITY  OF  CONCURRENT  PASCAL  TO  BMD  SOFTWARE 

We  have  found  GSIM  algorithms  involving  concurrent  operations  to  be 
easily  constructed  in  Concurrent  PASCAL.  However,  we  have  also  discovered 
certain  task  sequencing  requirements  common  to  BMD  software  which  are  not 
expressible  in  Concurrent  PASCAL.  Before  we  discuss  these,  we  will 
briefly  describe  the  Concurrent  PASCAL  Monitor  and  its  use  in  implementing 
an  example  algorithm  from  GSIM. 

The  language  structure  for  expressing  concurrent  operations  in 

26 

Concurrent  PASCAL  is  the  monitor.  A  monitor  is  a  single  programming 
unit  consisting  of  a  shared  data  structure,  local  variables,  procedures 
and/or  functions  which  operate  on  the  shared  data  structure.  Delay  and 
Continue  operations  and  Initialization  statements.  The  monitor  which 
controls  access  to  the  search  return  data  set  of  GSIM  is  shown  in 
Fig.  7.1.  The  monitor  schedules  exclusive  access  to  the  shared  data 
structure  when  a  call  is  made  upon  one  of  the  monitor  procedures  by  a 
concurrently  executing  process  (task).  This  scheduling  is  done  by  the 
virtual  machine  or  operating  system  routine  which  implements  the  monitor. 
Access  to  the  monitor  is  granted  on  a  first  come-flrst  served  basis.  The 
procedures  which  are  defined  within  the  monitor  are  local  to  the  monitor 
and  have  access  only  to  data  which  is  local  to  the  monitor.  Variables 
which  are  local  to  the  monitor  can  only  be  manipulated  by  calling  the 
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SnoSMnN  »  MONITOR  (  LI^^IT  i  INttGER  )  I 


VAp  RTNR  •  ARRAT  HF  SMRCHRtTURN  i 

SENOtfl,  RECEIVER  I  QUEUE  | 

HEAD,  tail#  length  I  integer  » 

PRpCERURF  entry  PUT  (  RETURN  I  SEARCHHETUHN  )  | 

BEGIN 

IE  LENGTH  s  LIHIT  THEN  DELAY  (SENDER)  I 
RTNOfTAlL)  :a  RE  TURN  | 

tail  j*  (Tail  ♦  1)  Huo  limit  j 
length  I*  length  ♦  1  t 

CONTINUE  (RECEIVER)  ) 

END  f*  PUT  A)  I 

PROCEDURE  Entry  get  (VAR  return  j  SEARCHRETuRN)  I 
BEGIN 

IE  length  a  0  THEN  RELAY  (RECEIVER)  ) 

RETURN  IS  HTUO  (HEAR)  | 

HEAD  |«  (HEAR  ♦  1)  HOO  limit  I 
length  I*  length  -  I  t 
CONTINUE  (SENDER)  | 

END  (A  GET  A)  I 

BEGIN  (A  initialize  a) 

HEAD  IS  0  I 
tail  I*  0  I 
length  IS  0 

END  (A  SROS  MONITOR  •)  t 


Figure  7.1.  Monitor  for  Search  Return  Data  Set 


monitor  procedures.  When  a  process  or  task  which  has  been  given  access 
to  the  monitor  executes  a  Delay  operation,  the  task  is  suspended  and 
exclusive  access  to  the  monitor  can  be  given  to  another  task.  Tasks 
which  have  been  suspended  are  reactivated  on  a  first  come-flrst  served 
basis  when  a  Continue  operation  is  performed.  In  summary,  monitors 
Implement  mutual  exclusion  of  concurrent  tasks  when  they  operate  on  a 
shared  data  structure  by  allowing  only  sequential  access  to  the  data 
structure.  They  prevent  tasks  from  performing  incorrect  operations  on 
the  shared  data  structure  by  requiring  explicit  definitions  of  the 
allowed  operations,  and  synchronize  cooperating  tasks  through  Delay  and 
Continue  operations. 
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We  will  now  give  an  example  of  a  monitor  which  controls  the  access 
to  the  data  structure  shared  by  concurrent  tasks.  Figure  7.2  shows  how 
a  verify  pulse  is  generated  in  response  to  a  search  return  in  GSIM. 

Radar  returns  are  placed  in  the  radar  returns  buffer  (RRB)  by  the  channel 
controller  task.  The  assimilate  radar  returns  task  then  classifies  the 
returns  according  to  type  and  places  all  search  returns  in  the  search 
returns  data  set  (SRDS).  The  generate  verify  pulse  task  generates  radar 
requests  for  verify  pulses  from  the  search  returns  and  places  these 
requests  in  the  radar  activities  queue  (RAQ) .  The  generate  radar  orders 
task  then  generates  radar  orders  from  the  radar  requests.  Notice  that 
the  SRDS  is  accessed  by  both  the  assimilate  radar  returns  task  and  the 
generate  verify  pulse.  This  is  the  data  set  we  will  implement  with  a 
monitor. 

Figures  7.1,  7.3  and  7.4  show  the  Concurrent  PASCAL  implementation 
of  the  search  return  data  set  monitor,  the  assimilate  radar  returns  pro¬ 
cess,  and  the  generate  verify  pulse  process,  respectively.  The  assimilate 
radar  returns  process  is  a  cyclic  task  which  gets  radar  returns  from  the 
RRB,  classifies  them  as  to  type  and  in  the  case  of  search  returns,  places 
them  in  the  SRDS  using  the  monitor  call  SRDS. PUT.  The  generate  verify 
returns  task  is  also  a  cyclic  task  which  retrieves  search  returns  from 
the  SRDS  using  the  monitor  call  SRDS. GET  and  creates  radar  requests  for 
the  radar  activities  queue.  The  SRDS  monitor  implements  a  queue  of  radar 
returns  using  an  array  data  structure.  The  monitor  contains  a  procedure 
to  place  entries  in  the  queue  and  another  procedure  to  retrieve  entries 
from  the  queue. 

It  is  possible  for  the  assimilate  radar  returns  process  and  the 
generate  verify  pulse  process  to  attempt  to  access  the  SRDS  simultaneously 
since  they  are  independent  tasks  and  we  have  made  no  assumption  about 
their  relative  speeds.  The  monitor  prevents  this  from  occurring  by 
allowing  only  one  of  the  processes  to  complete  a  call  to  a  monitor  pro¬ 
cedure  at  one  time.  Recall  that  this  mutual  exclusion  property  is 
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Figure  7.2.  Search  Return  Processing  in  GSIM 
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Figure  7.3.  Assimilate  Radar  Returns  Process 
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implicit  in  the  definition  of  the  monitor.  The  monitor  also  prevents 
either  process  from  attempting  to  place  or  retrieve  data  in  storage 
locations  beyond  the  length  of  the  queue.  For  example,  in  the  PUT 
procedure,  if  the  queue  is  full  (LENGTH  =  LIMIT)  then  the  assimilate 
radar  returns  process  is  delayed  until  the  generate  verify  pulse  p7:ocess 
retrieves  a  search  return  from  the  queue.  Similarly,  in  the  GET  proce¬ 
dure,  the  generate  verify  pulse  process  is  delayed  when  the  queue  is 
empty  (LENGTH  =  0)  and  is  only  allowed  to  continue  after  the  assimilate 
radar  returns  process  has  placed  a  radar  return  in  the  queue.  Therefore, 
we  see  that  the  monitor  has  been  successful  in  solving  the  problem  of 
exclusive  access  to  the  search  return  data  set  and  at  the  same  time  has 
synchronized  the  interaction  of  the  assimilate  radar  returns  process  and 
the  generate  verify  pulse  process. 

We  shall  now  use  GSIM  to  Illustrate  a  number  of  problems  that 
cannot  be  solved  using  the  monitor  construct.  Figure  7.5  depicts  the 
relationships  between  the  tasks  and  data  structures  used  in  the  genera¬ 
tion  and  processing  of  radar  requests.  The  generate  search  pulse, 
generate  verify  pulse  and  generate  track  pulse  tasks  all  place  requests 
for  the  radar  in  the  radar  activities  queue  (RAQ) .  The  generate  radar 
orders  task  takes  these  requests  from  the  RAQ  and  generates  a  radar 
schedule  satisfying  these  requests  which  does  not  exceed  the  constraints 
of  the  radar.  Unscheduled  requests  are  returned  to  the  RAQ.  As  will  be 
explained  in  the  next  section,  this  relationship  is  an  example  of  the 
reader's/writer's  problem  in  concurrent  processing.  A  read  operation  in 
this  case  removes  a  request  from  the  queue.  There  are  more  writers  than 
readers;  however,  in  a  BMP  software  system  it  would  be  preferable  to  let 
the  reader  have  priority  over  any  of  the  writers.  Suppose  we  implement 
the  RAQ  with  a  monitor  and  consider  the  case  where  two  of  the  three 
writing  processes  are  awaiting  access  to  the  RAQ  while  the  third  writer 
is  using  it.  If  the  generate  radar  orders  task  makes  a  read  request,  it 
will  have  to  wait  until  both  write  requests  have  been  processed.  The 
manner  in  which  exclusive  access  is  granted  by  the  monitor  (first  come- 
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Figure  7.5.  Radar  Activity  Processing  in  GSIM 
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first  served)  prevents  the  generate  radar  orders  task  from  getting 
access  to  the  RAQ  immediately  after  the  writer  which  is  using  the  queue 
has  finished.  However,  since  radar  time  is  a  scarce  resource,  we  may 
not  want  the  generate  radar  orders  task  to  wait  for  those  tasks  which 
are  generating  radar  requests.  Unfortunately,  there  is  no  facility  in 
the  Concurrent  PASCAL  monitor  for  implementing  this  priority 
arrangement. 

As  a  second  example,  consider  the  fact  that  we  allowed  the  generate 
radar  orders  Cask  to  get  radar  requests  from  and  put  radar  requests  into 
the  RAQ.  This  is  perfectly  reasonable  in  this  case.  Now  consider  the 
search  return  processing  which  was  depicted  in  Fig.  7.2.  It  would  not  be 
reasonable  in  this  case  to  allow  the  assimilate  radar  returns  process  to 
both  put  and  get  search  returns  from  the  SRDS.  There  is  nothing  in  the 
description  of  a  monitor  which  protects  us  from  this  programming  error. 
That  is,  the  monitor  construct  has  no  mechanism  to  protect  the  shared 
data  structure  from  being  accessed  by  a  process  using  an  improper 
operation. 

Figure  7.6,  which  depicts  track  processing  in  GSIM  Illustrates 
another  problem  with  the  monitor  construct.  The  object  track  data  set 
(OTDS)  is  the  track  file  for  GSIM.  The  OTDS  is  shared  by  the  assimilate 
radar  returns  process  which  places  track  records  in  the  OTDS  and  the 
generate  track  pulse  process  which  processes  these  track  returns  and 
generates  track  pulses  for  the  radar.  These  two  processes  also  share 
the  temporary  object  track  data  set  which  is  a  queue  of  radar  returns 
from  which  the  generate  track  pulse  process  matches  entries  in  the  OTDS. 
The  generate  track  pulse  process  is  allowed  to  perform  three  operations 
on  the  track  file:  match  a  track  record  with  a  radar  return,  update  a 
track  record,  and  destroy  a  track  record.  However,  the  monitor  imple¬ 
mentation  of  the  OTDS  does  not  allow  us  to  specify  the  order  in  which 
these  operations  are  to  take  place.  If,  due  to  a  programming  error  in 
the  generate  track  pulse  process,  a  destroy  operation  were  to  precede  a 
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OTDS  =  OBJECT  TRACK  DATA  SET  OR  TRACK  FILE 
TOTDS  =  TEMPORARY  OBJECT  TRACK  DATA  SET 


Figure  7.6.  Track  Processing  in  GSIM 


match  operation,  the  wrong  track  record  could  be  destroyed.  Although 
there  are  ways  in  which  the  monitor  procedures  may  be  programmed  to  check 
for  an  invalid  order  of  operations,  there  is  no  way  to  state  these 
constraints  explicitly  in  the  monitor  description. 

7.2  CLASSES  OF  CONCURRENCY 

In  this  section  we  shall  identify  several  classes  of  concurrency 
problems,  relate  them  to  problems  that  have  been  studied  previously  and 
identify  the  types  of  concurrency  which  occur  in  GSIM. 

By  studying  the  types  of  concurrent  processing  problems  discussed 

27-32 

in  the  computer  science  literature.  we  can  abstract  at  least  four 

dimensions  along  which  to  classify  these  problems.  Figure  7.7  shows 
these  dimensions.  From  the  first  two  dimensions,  the  number  of  processes 
which  are  allowed  to  access  the  data  structure  simultaneously  and  the 
number  of  shared  data  structures  which  each  process  requires,  we  can 
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Figure  7.7.  Dimensions  of  Concurrent  Processing  Problems 


identify  four  problems  in  concurrent  processing.  These  are  summarized 
in  Fig.  7.8.  In  the  case  where  only  one  user  is  allowed  exclusive 
access  to  a  single  shared  data  structure,  we  have  the  mutual  exclusion 
problem.  This  problem  is  typically  present  in  tasks  with  producer/consumer 
relationships.  If  more  than  one  process  can  be  given  access  to  a  shared 
data  structure  at  a  time,  we  have  the  problem  of  mutual  exclusion  between 
classes  of  processes.  Problems  of  this  type  usually  occur  when  processes 
can  be  classified  into  those  which  read  from  a  data  base  and  those,  which 
write  into  a  data  base.  If  a  single  process  requires  more  than  one 
shared  data  structure  at  a  time,  then  we  have  a  cooperation  problem. 

These  are  resource  allocation  problems  in  which  the  major  error  to  .be 
avoided  is  deadlock.  Finally  if  more  than  one  process  can  access  a 
shared  data  structure  simultaneously  and  each  process  must  access  more 
than  one  shared  data  structure,  we  have  a  problem  in  class  cooperation. 


Figure  7.8.  Problems  In  Concurrent  Processing 


The  operation  a  process  performs  on  a  shared  data  structure  Is 
another  dimension  by  which  concurrent  programming  problems  can  be 
classified.  In  the  most  general  sense,  a  process  can  create  (write)  an 
element  in  a  data  structure;  read  an  element  of  a  data  structure; 
change  an  element  of  a  data  structure;  or  destroy  (consume)  an  element 
of  a  data  structure. 


Lastly,  the  scheduling  rule  which  we  use  to  allocate  exclusive 
access  to  the  data  structure  can  be  used  to  differentiate  between  types 
of  concurrent  programming  problems.  In  the  case  of  the  monitor,  the 
processes  which  request  access  to  the  data  structure  are  given  access  to 
it  on  a  first  come-first  served  basis.  However,  as  we  have  shown 
previously,  other.;  scheduling  rules  may  be  desired. 

From  this  simple  classification  scheme  for  concurrent  programming 
problems,  we  can  identify  which  problems  occur  in  GSIM.  Figure  7.9  shows 
the  GSIM  tactical  software  processes  and  the  data  sets  that  they  access, 
and  Fig.  7.10  classifies  the  ways  in  which  each  data  structure  is  used. 
The  SRDS  and  TOTDS  are  producer/consumer  problems  and  were  easily  imple¬ 
mented  using  the  monitor  construct.  The  RAQ  and  OTDS  however  were  data 
sets  for  which  we  identified  difficulties  in  the  monitor  implementation. 
These  data  sets  exhibit  requirements  for  priority  access  and  multiple 
operations,  respectively.  There  are  a  number  of  examples  of  concurrent 
processing  which  do  not  occur  in  GSIM,  however,  we  expect  that  all  of  the 
types  of  concurrency  will  be  present  in  a  BMD  software  system.  For 
example,  if  there  were  multiple  processes  which  assimilated  radar  returns 
and  a  number  of  processes  which  generated  verify  pulses,  we  would  have 
classified  the  SRDS  as  a  problem  of  mutual  exclusion  of  classes  with  no 
priority. 

7.3  ASSERTIONS  FOR  CONCURRENT  PASCAL  MONITORS 

In  this  section  we  develop  assertions  for  the  search  return  data 
set  monitor  in  GSIM.  But  first  we  Identify  several  general  requirements 
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Figure  7.9.  Classification  of  Concurrency  in  GSIM 
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for  the  correctness  of  any  concurrent  processing  Implementation.  From 
these  we  define  correctness  criteria  for  the  class  of  problem  the  SRDS 
illustrates.  Finally  we  describe  a  symbolic  execution  technique  for 
deriving  verification  conditions  from  these  assertions. 

In  Ref.  27,  Dljkstra  identifies  four  criteria  for  the  correctness 
of  a  solution  to  a  mutual  exclusion  problem.  They  are: 

•  Mutual  exclusion  -  only  one  process  at  a  time  may  have 
access  to  a  shared  data  structure 

•  No  deadlock  -  when  a  shared  resource  is  requested  simulta¬ 
neously  by  several  processes,  it  must  be  granted  to  one  of 
them  within  a  finite  time 

•  .  No  starvation  -  when  a  process  acquires  a  shared  resource, 

the  process  must  release  it  again  within  a  finite  time 

•  No  busy  waiting  -  a  process  should  wot  consume  processing 
time  while  it  is  waiting  to  acquire  a  shared  resource 

In  addition,  our  solution  should  not  make  any  assumptions  about  the 
relative  speed  of  the  processes  since  in  general  we  cannot  predict  the 
order  in  which  processes  will  be  executed. 

The  search  return  data  set  has  been  identified  as  the  shared  data 
structure  of  a  producer/consuraer  problem.  To  prove  the  correctness  of 
our  monitor  solution  we  must  show  that  several  assumptions  are  not 
violated.  The  first  of  these  is  that  the  producer  and  consumer  are 
prevented  from  accessing  the  queue  simultaneously.  Since  this  is  an 
implicit  assumption  when  the  queue  is  implemented  using  a  monitor,  we 
cannot  prove  this  assumption  without  appealing  to  how  the  monitor  con¬ 
struct  is  Implemented.  Secondly,  we  must  show  that  the  data  structure 
behaves  as  a  queue.  That  is,  raescages  cannot  be  taken  from  the  queue 
when  it  is  empty,  a  new  message  cannot  be  placed  in  the  queue  fhen  it 
is  full  and  that  any  message  placed  in  the  queue  will  eventually  be 


retrieved  from  the  queue.  Thirdly,  we  must  prove  the  "no  blocking" 
criterion:  both  the  producer  and  consumer  cannot  be  waiting  for  each 

other  simultaneously.  For  the  monitor  implementation,  this  implies  that 
for  every  DELAY  statement  in  a  monitor  procedure  there  must  exist  a 
corresponding  CONTINUE  statement  and  that  if  any  DELAY  statement  has  been 
executed,  then  the  path  which  contains  the  corresponding  CONTINUE  state¬ 
ment  can  be  executed  to  remove  the  DELAY.  Finally,  we  must  show  that 
neither  the  producer  nor  consumer  can  continually  overtake  the  other  by 
always  gaining  access  to  the  shared  data  structure,  that  is,  that  the 
scheduling  of  the  monitor  is  fair. 

We  will  now  derive  the  assertions  which  describe  the  correct 
behavior  of  the  SRDS  monitor.  The  first  assertion  is  the  invariant  for 
the  correct  operation  of  the  queue.  As  shown  in  Fig.  7,1,  the  queue  is 
implemented  by  an  array  of  search  returns  whose  maximum  index  is  LIMIT 
-  1.  The  element  at  the  front  of  the  queue  is  indicated  by  the  index 
HEAD  and  the  element  at  the  end  of  the  queue  is  indicated  by  the  index 
TAIL.  Since  elements  are  inserted  into  the  array  in  a  circular  manner 
(after  an  element  has  been  entered  in  position  LIMIT  -  1  the  next  element 
will  be  entered  in  position  0) ,  the  length  of  the  queue  is  given  by  the 
expression: 

LENGTH  “  ABS(TAIL  -  HEAD)  +  1 

Therefore,  the  Invariant  assertion  for  correct  operation  of  the  queue  is 

0  _<  LENGTH  <  LIMIT  AND  LENGTH  =  ABS(TAIL  -  HEAD)  f  1 
This  assertion  must  always  be  true  in  the  monitor. 

We  can  however  make  stronger  statements  concerning  the  number  of 
elements  in  the  queue  after  DELAY  statements  and  before  CONTINUE  state¬ 
ments.  Figure  7.11  shows  the  SRDS  monitor  with  comments  which  indicate 
the  conditions  which  must  be  true  after  DELAY  and  before  the  CONTINUE 
statements  in  the  PUT  and  GET  procedures.  In  the  PUT  procedure,  the 
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Figure  7.11.  Search  Return  Data  Set  Monitor  with  Comments 


sending  process  is  delayed  if  the  queue  is  full.  This  process  cannot  be 
resumed  until  the  GET  procedure  is  called  and  the  CONTINUE  operation  is 
executed  indicating  at  least  one  empty  position  in  the  queue.  Conversely, 
the  process  which  calls  the  GET  procedure  is  delayed  if  the  queue  is 
empty.  It  cannot  be  restarted  until  the  PUT  procedure  is  called  and  its 
CONTINUE  operation  is  executed  signaling  at  least  one  element  In  the 
queue.  The  assertions  which  must  be  placed  after  the  DELAY  statements 
and  before  the  CONTINUE  statements  in  order  to  express  these  relation¬ 
ships  are  shown  in  Fig.  7.12.  In  general,  the  assertions  which  must 
surround  a  DELAY  statement  can  be  expressed  as 

{I  A  IB}  DELAY  {1  A  B) 

and  those  which  surround  a  CONTINUE  statement  as 
{I  A  B}  CONTINUE  {1} 

In  these  assertions,  B  expresses  the  condition  which  must  be  satisfied 
before  a  task  can  be  reactivated  following  a  DELAY  operation.  The 
f  ,  assertion  I  (the  monitor  invariant)  must  be  true  whenever  the  locus  of 

s 

control  changes  in  the  monitor.  Since  any  monitor  procedure  can  be 
executed  after  a  DELAY  operation,  this  Invariant  must  be  true  on  entry 
to  any  monitor  procedure.  In  the  case  of  the  SRDS  monitor,  the  invariant 
is  simply  our  first  expression  describing  the  correct  operation  of  the 
queue. 

The  final  assertion  in  each  monitor  procedure  must  describe  what 
result  the  execution  of  the  procedure  had  upon  the  queue.  For  the  PUT 
procedure,  this  is  that  an  element  is  entered  at  the  tail  of  the  queue 

RTNQ  (ABS  (HEAD  -  LENGTH)]  -  RETURN 

Similarly  in  the  GET  procedure,  the  assertion  must  state  that  an  element 
is  retrieved  from  the  head  of  the  queue 

RETURN  -  RTNQ  (ABS  (TAIL  -  LENGTH)] 

The  monitor  for  the  search  return  data  set,  complete  with  its  assertions 
is  shown  in  Fig.  7.13. 
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Figure  7.12.  Assertions  for  DELAY  and  CONTINUE  Statements 
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Figure  7.13.  SRDS  Monitor  with  Assertions 


To  generate  verification  conditions,  we  must  perform  symbolic 
execution  over  all  paths  between  any  two  assertions.  For  all  paths 
in  the  monitor  except  those  containing  DELAY  statements,  this  is  the 
same  method  as  we  have  used  for  other  programs.  After  a  DELAY  statement, 
however,  any  other  monitor  procedure  may  be  executed.  So,  in  the  general 
case,  we  must  generate  verification  conditions  over  all  paths  in  all 
other  monitors!  Fortunately,  we  can  use  the  procedure  we  have  developed 
for  subroutine  calls  to  make  this  problem  less  difficult. 

Since  the  verification  condition  generator  and  simplifier  in  the  ’ 

Software  Quality  Laboratory  cannot  as  yet  analyze  Concurrent  PASCAL,  we 
will  not  show  all  the  verification  conditions  and  proofs  for  the  SRDS 

monitor  generated  automatically.  However,  as  a  manually  derived  example, 

wa  will  show  that  the  "no  blocking"  criterion  holds  for  thl'’  monitor. 

First  assume  that  the  PUT  procedure  has  been  called  and  that  the  queue  is 

full.  Therefore  the  process  which  called  the  PUT  procedure  is  delayed 
and  the  condition 

LENGTH  =  LIMIT  ^ 

is  true.  The  verification  condition  at  the  DELAY  statement  is  therefore 

0  £  LENGTH  •=  ABS  (TAIL  -  HEAD)  +  1  £  LIMIT 

A  LENGTH  -  LIMIT 

which  simplifies  to 

0  £  LIMIT  -  ABS  (TAIL  -  HEAD)  +  1  £  LIMIT 
and  finally  gives  the  expression 

0  £  LIMIT  -  ABS  (TAIL  -  HEAD)  +  1 

Since  there  is  only  one  sending  process,  the  only  monitor  procedure  which 
can  be  called  next  is  the  GET  procedure.  Examining  the  paths  in  the  GET 
procedure  we  find  that  the  process  which  Invokes  it  can  be  delayed  if  the 
condition 

LENGTH  ■  0 

) 
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is  true.  The  verification  condition  at  the  DELAY  statement  in  the  GET 


procedure  is 


0  £  LENGTH  =  ABS  (TAIL  -  HEAD)  +  1  .<  LIMIT  A  LENGTH  =  0 
which  simplifies  to 

0  =  ABS  (TAIL  -  HEAD)  =  1  £  LIMIT 

Both  of  these  expressions  must  be  true  for  each  process  to  bo  writing  on 
the  other  and  since  the  expression  ABS  (TAIL  -  HEAD)  +  I  appears  in 
both  verification  conditions  we  obtain  the  combined  expression 

0  =  ABS  (TAIL  -  HEAD)  +  1  =  LIMIT 

which  implies  that 

LIMIT  =  0 

Since  LIMIT  is  the  length  of  the  queue,  the  two  processes  cannot  block 
each  other  unless  the  queue  has  a  length  of  zero. 
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APPENDIX  A 


GRAMMAR  DESCRIPTION  FOR  VERIFIABLE  PASCAL 


In  the  listing  which  follows  is  the  syntactic  description  of 

19 

Verifiable  PASCAL  as  presented  to  the  Compiler  Writing  System  (CWS). 

The  imbedded  semantic  actions  used  to  complete  the  Verifiable  PASCAL 
Preprocessor  have  been  removed  from  the  data  for  clarity  and  brevity. 

In  preparing  this  grammar,  close  compatibility  with  the  distributed 
version  of  the  CDC  6000  standard  PASCAL  compiler  was  maintained.  For 
example,  the  names  of  standard  procedures  and  functions  for  that  compiler 
are  defined  in  the  grammar,  and  are  treated  by  the  preprocessor  as 
reserved  Identifiers. 

In  order  to  permit  more  effective  error  recovery  in  the  generated 
preprocessor  the  grammar  input  to  CWS  departs  slightly  from  the  descrip¬ 
tion  shown  in  the  syntax  diagrams  (see  Sec.  3.2.1).  For  example,  the 
rule  for  statement  list  <STALIST>  does  not  require  a  semicolon  to  separate 
consecutive  statements,  but  the  syntax  diagram  does. 

The  grammar  is  stated  as  a  set  of  rules  in  a  form  similar  to  BNF; 
non-terminal  *  list  of  elements 

As  used  in  the  grammar  for  Verifiable  PASCAL,  the  elements  are: 

IDENT,  a  PASCAl,  identifier 
ENTIER,  a  PASCAL  Integer 
REEL,  a  PASCAL  real  number 
CHAINE,  a  PASCAL  character  string 

•V 

VIDE,  an  empty  element 
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FDF,  the  end-of-file 

E  and  =,  delimiters  for  a  reserved  word  or  a  reserved  Identifier 
<  and  >,  delimiters  for  a  non-terminal  identifier 
V,  to  separate  alternatives 
[  and  ],  to  group  elements 

*[  and  ]*,  to  signify  that  zero  or  more  of  the  enclosed  may  occuv 
+[  and  ]+.  to  signify  that  one  or  more  of  the  enclosed  occurs 

to  separate  the  left  part  of  the  rule  for  a  non- terminal  from 
the  right  part 

$,  to  signify  the  end  of  a  rule 

The  grammar  Is  shown  In  Fig.  A.l  preceded  by  a  sequence  of  options 
for  the  first  two  phases  of  CHS.  Rules  of  grammar  begin  after  the  symbol 
REGLE  and  terminate  with  the  8yii4)ol  FIN. 


) 
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programme  ef:«LGEN 


t 

DEBUT 

2 

PASCALV 

3 

OFTICTS 

'4 

FQICTICN 

5 

FTEPMIKA 

6 

GFAMMtIRF 

7 

Rfounr 

S 

LLUM 

9 

t 

1  2 

OPTICES 

1 1 

AliCLl  IS 

12 

MOISCLfS 

13 

OPERATtUBS 

U 

RESERVES 

15 

PRCCSYPBCLCAPTURE 

16 

aUAt  CSC.fiCUPES 

17 

UI'ILICEM  10 

19 

MAVICEM  997 

19 

LCMGZCSFf  M400fl 

20 

LCSCCHIf  E9  0 

21 

MAxi;ecFiFri3 

22 

OELCOM*'£KT<,.*» 

23 

t 

214 

terminal 

25 

lOFNT 

26 

EMTIER 

27 

PEEL 

29 

CHAIRE 

29 

FOE 

30 

RCCLE 

31 

<AXIOM>  * 

32 

«PROCRAM»  EOF 

' 

33 

s 

3<t 

<PROGPAM>  * 

35 

(  f  =0PriONS=  «OPTIONLIST>  )  *  VIDE  1 

36 

C  (  iPROCRAHH  «PROCHEAO> 

J  V  VIDE  1 

37 

<BLOC<»  =41 

39 

t 

39 

«0PTI06LIST»  » 

<•0 

•f  <SHITCH»  =»=  <OPTIOR» 

)• 

<•1 

t 

■i2 

«SWITCH*  * 

<•3 

zASSERTi  V  HuMITSr  v  HCONTROLs  »  sRIGMTS: 

U4 

S 

(•5 

<OPTICA»  * 

W6 

=OR=  »  =OFF=  V  =ASIS= 

47 

t 

49 

<PROCHEAO>  * 

49 

lOCNI  4FILCLIST>  iJ= 

50 

% 

51 

<FILELIST»  « 

52 

=(=  «FILES>  =)= 

53 

t 

54 

«FILES»  * 

55 

<FILEIO»  *1  =,s  «FlLEIO> 

!• 

56 

1 

57 

<FILEI0»  • 

59 

(  lOENT  {  •«=  V  VIDE  1  1 

«  slNPUT-  V  EOUTPUT 

59 

S 

Figure  A.l.  Grannnar  for  Verifiable  PASCAL 


63 
6 1 
62 
63 
66 

65 

66 
62 
65 
65 
73 

71 

72 

73 
76 
75 


«BLOCK>  » 

1  I  6LA8ELH  <LA9eLP*P.T>  1  v  VIDE  > 

(  (  6C0NSTE  <CONSTPAPT'>  I  v  VIDE  J 

t  I  iTYPt=  <TVPEPSPT>  I  V  WIDE  J 

(  (  EVAPr  <VARPART>  1  v  VIDE  ) 

(  'I  t  rPROCEOUREE  <PROCPART>  J  v  t  iFUNCTIONS  <FUNCPART>  J  J»  1 
<300Y> 

5 

<QOOY>  » 

EBECIN:  <STALIST>  EENOs 
t 

«LAQELPAPT>  « 

•I  ENTIER  •  =,i  •  =t=  »* 

S 

<C0NSTP4RT»  « 

•t  '■CONSTOEC>  V  =!=  ]• 


76 

77 

78 

79 
an 
61 
62 
63 
66 

95 
66 
67 
66 
69 
93 

91 

92 

93 

96 

95 

96 

97 
96 
99 

100 

101 

102 

133 

106 

135 

106 

107 

101 

109 

110 
111 
112 
113 
tl« 

115 

116 
117 
116 


1 

«CONSTOEC>  « 

lOENT  =>:  «CONSTANT»  <UNITSOEC> 

% 

<COKlSTt*<t*  « 

<C0NST4»  *.  lOEMT 

t 

<CaNSTA>  > 

CHAINE  »  ETRUEE  «  EFALSEs  v  EHAXINT:  «  ENILE  *  ENTIER  «  REEL 

•  t  I  =♦=  »  E-=  1  t  ENTIER  V  REEL  »  lOENT  >  1 

« 

<UNIT£0£C>  » 

I  EUNITSr  <UNITSTERH>  1  *  WIDE 

'  * 

<UNITSTER«»  « 

•UHITSFACTOR*  •(  I  =*s  v  s/a  |  «UNITSFACTOR>  )• 

t 

«UNIT5FACI0R»  » 

I  lOENT  «  ENTIER  «  REEL  «  I  :l:  <UN1TSTERN>  r)s  I  I 
♦t  =••=  <UHlTSPONER»  1* 

1 

<UNITJPOKFR»  • 

nCNT  V  ENTIER 
5 

<TTPEPART>  s 

•t  <IYPEOEC»  »  =1=  1* 

t 

<TYPEOIC>  » 

lOENT  s»s  <TYPE» 

t 

<TYPE»  • 

t  C  iPACKEOs  •  VIDE  1 
(  (  EARRAYr  <ARR1YQEC>  I 
»  1  EFILEH  EOFE  «TYPE>  I 

•  (  ESEGNENTEOE  SEILEs  SOES  <TYPE»  ) 

V  (  ESETE  EOFE  <SINPL£TYPE>  1 

«  I  ERECCROE  <FieLOLIST>  EENO:  I  >  1 

•  I  E»E  lOEHT  1 

V  <SXNPLETYPE> 
t 

«ARRAY0EC>  ■ 

sis  «SXNPtCTYPC»  •!  s»s  <SIHPLCTTPC»  J*  sis  SOEs  <TYPC» 

S 
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<SIHFLfTYPl>  = 

I  :INTE&EF£  v  =RE«L;  ^  ^TEXT:  »  rCHAR^  v  =BOOLEAN=  »  iALFAz 

•  I  in  <IDLIST>  I 

»  I  <CONSTA>  =..=  <CONSTANT>  1 
V  lOENT  t  I  =..=  <CONSTANT>  >  *  VIDE  1  ) 

<UIIITSOEC> 

% 

<FI£LCLIST»  = 

{  <riXEOPART>  t  t  =rASE=  «VA«IANTPART>  1  v  WIDE  1  1 
»  I  i  {  rCASe=  <VA«IANTPART>  1  w  VIDE  1  ) 

t 

<FIxrCFAPT>  X 

♦t  «FIXEOO£C>  -  !♦ 

s 

<FlXEOOEC>  ' 

♦  lOLIST*  I  =1=  w  =•/.=  1  <TYPE» 

t 

<VARUMPARr»  * 

lOENT  (  I  I  HtS  •  =Z=  I  lOENT  I  «*  VIDE  1  rOFr  <CASE> 

•t  zPF;  <CASE»  1* 

t 

<CASE>  * 

<C0NSTANT>  •!  =,i  <COMSTANI>  I*  I  its  »  jX=  1  =C=  <FIELDLIST>  =)= 
t 

<VARPAPT>  X 

•t  <VA«OEC>  V  =;;  !• 

<VAROEC>  * 

<IDLIST»  I  =lr  *  sXi  }  <TVPE> 

t 

«IOLIST>  * 

IDENT  •(  =,=  lOENT  !• 

t 

<PRCCPART>  = 

<PROChEAO>  iJi  <PROCeOOY>  =5i 
t 

«FUNCFART»  » 

<PSOCHEAO>  f  sis  *  sXi  I 

(  lOENT  V  zInTFGER:  v  -BOOLEAN:  «  :R£AL:  «  =CHAR:  «  :ALFA:  I 
=;i  <PROCeOOY>  :J: 

t 

«PROCPtAD>  X 

lOEHT  <PARAHLIST> 

t 

<pRCCtcoy>  * 

rFORIRAN:  v  HEXTERN:  »  rFORWARD:  *  <BLOCK> 

f 

<FAPANIIST>  X 

f  :<=  «PARA«3>  1  V  WIDE 

t 

<PARAPS>  * 

<PARAN»  "I  =t=  xPARANx  )» 

t 

<PARAP>  X 

t  iPROCEOURE:  «IOLIST»  I 

»  I  (  =FUNCTION=  V  iVAR:  v  VIDE  I  <IDLIST>  I  =1=  *  =1Ci  1 
t  lOEMT  V  zINTEGCR:  »  iBOOLEAN:  *  SREAL:  •  ICHAR:  *  =ALFA:  v  :TEXT=  1 

t 

«STALIST»  X 
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«ST*TC«^ 


<STAL*BeL 


ENTtEH  t  =t=  *  =•/.;  ) 


<STATYfe> 


«1FSTA> 


<CASESTA> 


«CASP>  ■ 


<CASELABE 


<WHILESTA 


«REPFATST 


<FOPSTA> 


!  ^STATEMENT*  v  =5:  !• 


STALAaEL>  w  «STATYPE» 


EBESIN:  <STALI3T>  EENOE  I 
t  EIFH  <tFSTA>  1 
t  ECASEr  «CAS£STA>  I 
f  :MMILE=  <MH1LESTA>  ) 

.  EREPEAF;  <REPEAT$TA>  1 
I  EFORE  <FORSTA»  1 
(  EMirrtE  <miih';ta>  i 
t  EGOIOE  «GOTOSTA>  I 

t  t  lOENT  »  <srap9oc»  i  t  i  eie  «invlist»  =»=  i 
t  <3UALLISt>  I  =1*:  »  =%«=  I  <EXPRESSI  (1M»  1 
t  I  =t*=  V  =Z«E  1  <EXPRESSION>  J  v  WIDE  1  > 
t  EASSERTE  <AS3ERTSTA»  1 
t  EINIIIALE  <ASSEPTSTA>  1 
C  EFINALE  «A3SERTSTA»  ) 
t  EIMPUIE  «IOLISI»  > 

(  EOUTPUTE  <IDLIST»  > 


COSOITIOKAi.> 

(  rCRlFE  'CONDITIONAL*  1» 

(  EELSEE  <SIALIST>  I  •  WIDE  > 
sEKDIFE  V  I  EENOE  EIFE  )  I 


<CCNOniONAL>  * 

<EXPRESStON>  STHENE  «STALIST» 


EXPRESSION*  SOFE  I  <CASP*  *  VIDE  > 
I  EOFE  I  <CASP»  *  VIDE  1  I* 
EENDCASEE  «  I  EENOE  ECASEE  >  1 


CASELABEL>  <STALIST> 


CONSTANT*  •!  EtE  (CONSTANT*  J*  (  El:  «  EXE  1 


EXPRESSION*  SOOE  (STALIST* 
EENONHILEE  »  t  EENOE  E'«NILEE  I  I 


STALIST*  EUNTILE  (EXPRESSION* 


OENT  I  El«s  «  EX>E  1  (FORLIST*  EDO:  (STALIST* 
EENOFORE  «  I  EENOE  EFORS  I  I 


(FORLIST*  > 

(EXPRESSION*  I  ETOE  «  EDOMNTOE  1  (EXPRESSION* 
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2  jr  t 

Z38  «''»  >ST4>  = 

ZJ3  «V4RLIST>  =00=  <ST»LISt> 

2->0  I  =EN3WITH=  V  I  :eND=  =MITH=  )  I 

241  t 

242  <V4RLIJT»  * 

243  <tfARUaLE>  •{  =,=  <V*RIABLE>  I* 

244  $ 

245  <V4Rl«eLF>  > 

246  lOENT  (  <QUALLIST>  v  VIDE  1 

242  t 

24S  <CUALLIST>  * 

249  ♦!  (  =(=  <E)(PRESS:ON>  •!  =,=  <EXPRESSION>  1*  =1=  ! 

253  V  t  =.=  lOEMT  3 

251  »  =♦=  1* 

252  t 

253  «COTOSTA>  » 

254  ENTIER 

255  t 

256  «4SSEPTST4*  = 

257  <4SSERrEXP>  (  I  =FAIL=  <STALIST> 

25S  t  =EN0F4IL=  »  I  sEHO=  =EAIL=  1  )  1  »  VIDE  1 

259  t 
263  <4SSERTEXP>  « 

261  «aU4NTEXP>  I  (  =»=  <QUANTEXP»  I  v  VIDE  1 

262  % 

263  <aU4KTrxp>  « 

264  t  <EXPRESS10N>  1  v  (  1  ZALLi  v  jSOHEi  1  «aUANTAIL>  1 

265  t 

266  <QU4NTAU>  « 

267  ziz  lOENT  zIN=  <QUANTI.IST>  ilS:  <ASSERTEXP>  •)  = 

266  t 

269  «CU4t;Tl,IST»  * 

270  'EXPRESSION>  I  =TOr  »  sOOHNTOs  )  <EXPRESSION> 

271  I 

272  <1NWLIST>  • 

273  <P(VP4R»  •!  =,=  «INVP4R>  !• 

274  t 
2*5  <IHVP4R»  » 

276  (  <EXPRESSION»  *1  I  =ls  »  =•/.=  1  «EXPRESSION»  3*  3 

277  *  =INPUT=  •  rOUTPUTs 

276  T 

279  «EXPRESSION>  « 

260  <SIMPLEE7P> 

281  (  (  (  z*z  »  z*z  »  z»r  *  rXr  »  r!z  *  sis  »  r«»s  *  r<»=  *  r»* 

262  *  =E0=  V  =LC=  *  sNE;  v  ;CEi  v  =LT=  v  =CT=  v  iINz  3 

2>3  <SIMPLEEXP>  3  v  VIOE  1 

234  t 

265  «SIPFLEEXP>  » 

236  t  (  =♦=  «TERM>  3  v  t  =-=  <TERN>  3  *  <TERP>  3 

287  t  =*=  V  =-=  V  =0R=  »  =*=  3  <TERI1>  3* 

286  6 

289  <TERP>  > 

290  «FACT3R>  *1  (  =•=  »  =/=  v  =OIVi  »  iMOOr  v  =ANO=  v  =»=  3 

291  <FACTOR>  3* 

292  1 

293  <FACTCR>  ■ 

294  (=(:([  <SET»  sl=  3  «  =3:  3  3 

295  *  I  I  =NOT=  »  i-E  3  €FACTOR>  3 
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?16  »  C  r(=  «fXPRESSIOM>  H»  =  1 

297  »  t  (  IDEMT  v  <STOFUNC»  1 

298  t  t  =(=  <INVL1ST»  i>:  1  »  <QUALLISr»  v  VIDE  1  ) 

299  »  CMAINE  V  REEt  v  ENTIER  v  =NIL=  *  jT/^UEE  *  EFALSEE  v  EHiXINT 

300  S 

301  <SET>  * 
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303  t 

304  <HERBER>  > 

305  «EXPRESS10N>  I  I  E..E  «exPRESS10K>  I  *  VIDE  1 

336  t 

307  <STOPRCC»  * 
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3J9  »  ERESETE  «  EREMRITEE  v  EUNPACKE  »  EHRITEE  »  EWRITELNE 

310  •  EOATEE  •  EGETSEGE  »  EHALIE  *  ELINELIMITE  »  EMESSACEE 

311  V  EPUTSEGE  •  ETIHEE  •  EOlSPOSEE  v  ERELEASEE 

312  t 

313  <STCFURC>  « 

314  EARSE  «  EARCTANE  «  ECHRE  »  ECOSE  «  EEOEE  »  EEOLNE  »  EEXPE 

315  »  ELNE  •  EQOOE  •  EOROE  »  EPREOE  *  EROUNOE  •  ESINE  •  ESQRE 

316  «  ESCRTE  «  ESUCCE  »  ETRUNCE 

317  «  ECAROE  v  ECLOCKE  «  EEOSE  »  EEXPOE  «  EUNOEFINEDi  w  ERANOOH: 

318  t 

319  FIN 
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APPENDIX  B 


TRANSLATION  TEMPLATES  FOR  VERIFIABLE  PASCAL 


The  templates  for  translating  Verifiable  PASCAL  control  structures 
and  executable  assertions  are  outlined  below.  Where  appropriate,  keywords 
are  retained  in  the  translated  text  as  comments  (e.g.,  ENDIF  becomes 
(*ENDIF*)).  Original  comments  are  suppressed. 

For  the  option  ASSERT  *■  ON,  the  following  variable  declaration 
statement  is  Inserted  into  the  VAR  group  of  each  module: 

ASSERT  ;  BOOLEAN 

If  a  module  has  no  VAR  group,  one  is  inserted  automatically. 

For  a  Boolean  function  which  contains  only  assertion  statements, 
an  assignment  statement  is  generated  at  the  end  of  the  statement  list 
for  the  value  of  the  function: 

function  name  :■  ASSERT 

The  templates  shown  below  are  valid  only  for  an  assertion  expression 
which  does  not  contain  another  assertion  expression  as  a  subexpression. 


J 


Statement 

Source 

Translated  Source 

IK 

IF  expression  THEN 

IF  expression  THEN 

statement  list 

BEGIN  statement  list 

ORIF  expression  THEN 

END  (*0R1F*) 

statement  list 

ELSE  IF  expression  THEN 

BEGIN  statement  list 

ELSE 

END 

statement  list 

ELSE 

BEGIN  statement  list 

END  IF 

END  (*END1F*) 

CASE 

CASE  expression  OF 

case  label  list; 

CASE  expression  OF 

statement  list 

BEGIN  statement  list  END 

OF  case  label  list: 

;(*OF*)  case  label  list: 

statement  list 

BEGIN  statement  list  END 

END  CASE 

END  (*END  CASE*) 

WHILE 

WHILE  expression  DO 

WHILE  expression  DO 

statement  list 

BEGIN  statement  list 

END  WHILE 

END  (*END  WHILE*) 

FOR 

FOR  control  variable 

FOR  control  variable 

:•  for  list  DO 

:■  for  list  DO 

statement  list 

BEGIN  statement  list 

END  FOR 

END  (*END  FOR*) 

WITH 

WITH  variable  list  DO 

WITH  variable  list  DO 

statement  list 

BEGIN  statement  list 

END  WITH 

END  (*END  WITH*) 

INITIAL, 

INITIAL 

(*keyword*')  assertion  expression 

ASSERT, 

ASSERT 

expression 

code; 

FINAL 

FINAL 

(without  fall  clause) 

IF  NOT  ASSERT  THEN 

WRITELN  (‘ASSERT  FAI.SE 

AT  TEXT  LINK  statement 

number  FOR  STATEMENT 

AT  module  statement') 

FAIL  statement  list 

IF  NOT  ASSERT  THEN 

END  FAIL 

(*FAIL*)  BEGIN 

statement  list 

END  (*END  FAIL*) 

B-2 


assertion  ^ 
expression 


first  order  expression 
p  AND  q 


ASSERT  p  AND  q 


p  OR  q 
p  .>  q 


ALL  (1  IN  m  TO  n  IS  p) 

ALL  (1  IN  m  DOWNTO  n  IS  p) 

SOME  (1  IN  m  TO  n  IS  p) 

SOME  (1  IN  m  DOWNTO  n  IS  p) 


ASSERT  p  OR  q 

ASSERT  :-p; 

IF  ASSERT  THEN 
BEGIN 

ASSERT  q 
END 
ELSE 

ASSERT  TRUE 

ASSERT  TRUE;  1  m; 

WHILE  (1  <-  n)  AND  ASSERT  DO 
BEGIN  ASSERT  p; 

1  1  +  1  END 

ASSERT  TRUE;  1  m; 

WHILE  (1  >-  n)  AND  ASSERT  DO 
BEGIN  ASSERT  p; 

1  1  -  1  END 

ASSERT  FALSE;  1  m; 

WHILE  (1  <-  n)  AND  NOT  ASSERT  DO 
BEGIN  ASSERT  p; 

1  :=  1  +  1  END 

ASSERT  FALSE;  1  m; 

WHILE  (1  >-  n)  AND  NOT  ASSERT  DO 
BEGIN  ASSERT  p; 

1  1  -  1  END 


Templates  are  valid  for  only  where  p  and  q  are  PASCAL  expressions 
of  Boolean  type,  1  is  a  PASCAL  integer  variable,  and  m  and  n 
are  PASCAL  expressions  of  Integer  type. 


APPENDIX  C 


TRANSLATION  TEMPLATES  FOP,  IFTRAN  WITH  ASSERTIONS 

The  IFTRAN  preprocessor  recognizes  a  set  of  assertion  statements 
which  can  be  translated  to  compilable  FORTRAN  and  executed.  The  default 
translation  of  IFTRAN  assertions  is  into  FORTRAN  comments.  This  section 
describes  the  IFTRAN  commands  which  cause  executable  assertion  translation. 

The  executable  form  of  the  INPUT  and  OUTPUT  statements  writes  the 
current  values  of  all  variables  in  their  variable  lists.  Thus,  the  INPUT 
(OUTPUT)  statement  prints  input  (output)  variables  of  a  routine  when  used 
as  described  in  Sec.  3.2.  The  commands  associated  with  INPUT  and  OUTPUT 
statements  are 

IFTRAN  COMMAND  FUNCTION 

TRAC  Trace  input  and  output  values 

TROF  Resume  default  mode  of  no  tracing 

UNIT  name  Use  as  output  unit  the  FORTRAN  variable  or 

constant  name 

Figure  C.l  is  an  example  of  a  subroutine  which  uses  the  trace  commands  to 
indicate  its  input  and  output  values  whenever  it  is  executed. 

The  executable  form  of  INITIAL,  FINAL,  and  ASSERT  statements  evalu¬ 
ates  the  first-order  logic  expression  asserted  with  current  values  of 
program  variables.  If  the  expression  is  false,  an  error  message  is 
printed  and  any  associated  FAIL  BLOCK  is  executed.  The  syntax  of  INITIAL, 
FINAL,  and  ASSERT  statements  with  or  without  FAIL  clauses  is  defined  in 
Sec.  3.3.  The  commands  associated  with  ENTRY,  EXIT,  and  ASSERT  statements 


IFTRAN  COMMAND 


FUNCTION 


Check  assertions  for  validity  during 
execution 

Resume  default  mode  of  no  checking 

Use  the  FORTRAN  variable  or  constant  NAME 
as  output  unit 

Provides  the  name  of  a  routine  which  has 
ENTRY,  EXIT,  or  ASSERT  statements 

The  "ASON"  and  "ASOF"  and  "UNIT"  commands  are  global  commands  in 
that  they  refer  to  more  than  one  routine.  The  "MCDN"  command  is  local 
to  an  individual  routine.  It  can  occur  anywhere  that  a  logical  declara¬ 
tion  statement  is  legal  in  FORTRAN.  Deck  specific  executable  assertion 
checking  is  turned  on  by  the  "MODN"  command.  An  example  of  a  subroutine 
which  will  produce  exception  reports  when  executed  is  given  in  Fig.  C.2 

The  executable  code  for  each  type  of  assertion  expression  is  given 
in  Fig.  C.3. 


ASON 

ASOF 

UNIT  name 

MODN  name 


( 


SUl3M(,UriKE  KLTPLY(A,B,t.N) 

ctmac 

CIMLImSiCN  M(l«l)iB(l<l)iC(lfl) 

LATA  LULT  /fa/ 

KvPLT  (im.A.B) 
iJCi( 

.  LO(j=l«N) 

.  .  lUtfOKEt  COMPUTE  NEW  AKKAY  ELEMENT  ) 

.  ENU  UO 

End  1.0 


BLOCK  <  COMPUTE  NEw  ARRAY  ELEl“.EtJT  ) 

•  S  >  0. 

.  uO(K=l.N) 

.  .  S  =  S  ♦  A(1,K)  •  B(K,J> 

.  ENO  00 
.  C(i.O)  s  S 
LNU  OLUCK 
CuTPUT(C) 

return 

END 


Figure  C.l.  Trace  Commands 


FUNCTION  SORI(A) 

CASON 

CROON  SORT 
CUNIT  LOUT 

LATA  lout  /fa/ 

1MT1Al(  a  .OT.  0  ) 

A  =  A 

WHILE!  AeS(X>A/X)  .GT.  l.E-G  ) 

.  X  =  (X  «  A/X)/2 
END  WHILE 
SORT  s  X 

FINAL!  ABS!SCRT**2  -  A  )  .LE.  i.E-fc  ) 

return 

end 


Figure  C.2.  Executable  Assertion  Commands 


ASSERTION  EXPRESSION 
(P  .AND.  Q) 


(P  .OR.  Q) 


(P  .IMP.  Q) 


(ALL  I  IN  (l.N)  (P)) 


ASSERT  =  P 
IF  (ASSERT) 

ASSERT  =  Q 
ENDIF 

ASSERT  =  P 
IF  (.NOT.  ASSERT) 
ASSERT  =  Q 
ENDIF 

ASSERT  =  P 
IF  (ASSERT) 

ASSERT  *  Q 
ELSE 

ASSERT  *  .TRUE. 
ENDIF 


ASSERT  .TRUE. 

I-l 

WHILE  (I  .LE.  N  .AND.  ASSERT) 
ASSERT  «  P 

IF  (ASSERT)  1=1+1 
ENDWHILE 


(SOf€  I  IN  (1,N)  (P))  1=1 

(I  .6T.  N  .OR.  ASSERT) 

-4 

ASSERT  *  P 

IF  (.NOT.  ASSERT)  1=1+1 
UNTIL 

(I  .GT.  N  .OR.  ASSERT) 


Figure  C.3.  Translation  Templates  for  IFTRAN  Assertions 
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VERIFICATION  OF  TIMES 
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CCMEMS  OF  FILE/COMFANO  PRIOR  TO  STARTUP  OPERATION 


KtW  library  =  TLRP. 

SI  ART .lAROUAGEsIFTRAN, 
CflSlC. 

Ftp  ALL  RGLuLES. 

S IRUCTURAL. 
print  .R'OtULL. 
VtG«PATH=2.X«2 
VtGtHEPLALE, 

P  .GL.  1  s  B  .6T<  0 

•  tND. 

VCGiPATH=2tli3 
VtG.PATR=2.2.2 
vtG. replace. 

Y  .GT.  1  s  Y  .6E.  2 

•  tNC  • 

VtGiPATHs2«2i9 
ENC  FCR. 

ENC. 


VCGtPATHs2iXi2 


SUbROUTtKE  TIKES  (  Ai  Bi  X  I 


LINE 

PAIH  SOURCE  text 

1 

SUBROUTINE  TImES 

(  A 

11 

INITIAL  (  B  •GC. 

0  ) 

12 

SUN  s  U 

13 

Y  s  B 

19 

WHILE  I  Y  .NE.  0 

> 

18  (  1) 

.  ASSERT  (  SUM 

.ee. 

verification  CONCITICN  SUBROUTINE  TIKES  I  A<  B<  X  ) 

lii<e  verification  condition 

11  e  .GL.  b 

ANU 

19  B  .NE.  0 

...........  IP, plies . . . . . 

X«  0  4  A  .EO.  A  •  (  B  •  (  B  •  1  )  )  .and.  B  .  1  .BE.  0 
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«  !  I  I  V  '>!«• 


% 


VtGiPATH=2.1f2 


subroutine  times  (  A«  B«  X  > 


CLALSE 

1 

verification 

8  .GT.  U 

CONDITION 

AnrLALa  - 

2 

B 

.GE.  1 

rlle 

B 

.GL.  1  s 

B 

•  GT.  0 

replace 

8 

.GE.  1  3 

B 

.GT.  0 

VCGtREPLACC. 


subroutine  times  (  a*  Bf  X  ) 


FKOCF  of  verification  COKOXTION  COMPLETED 


VCG.PATh=2«l«J  SUBROUTINE  TIMES  (  Ai  B*  X  ) 


LI(,E 

PAIB  .SUUMCe  TLXT 

1 

SUoRQuriNE  TIMES 

( 

A.  B 

11 

INITIAL  (  e  .GC. 

0 

} 

12 

SUM  3  0 

13 

T  3  B 

15 

RHILE  (  Y  .NE.  0 

» 

21 

FINAL  (  A  .EO.  A 

• 

B  ) 

VERIFICaTIUN  CUNCITICN  SUBROUTINE  TIMES  (  A*  B«  X  > 

LINE  verification  CCNClTlON 
11  B  .bE.  b 

AND 

15  B  *£0.  0 

- . —  IMPLIES . . . 

21  0  .CO.  A  «  a 


VCG.PATHs2tltS  SUBROUTINE  TImES  (  A.  Bi  X  ) 

proof  of  verification  CONDITION  COMPLETED 
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Vtp,I’ATh=iJ'2>2 


SlJBNOUTINL  T1ME.S  (  A«  B«  A  ) 


LINL 


HATH  SOUHCE  TEXT 


lb 

16  (  1) 

17  (  1) 
la  (  1) 
19 

15 

18  (  1) 


nHlLE  (  T  .M.  U  I 
,  liUi“  =  bCK  ♦  A 

.  V  =  r  -  1 

.  assekt  (  Sum  .eu.  a  «  i  b  -  y  )  •anu<  y  .ge.  o  > 
enukhile 

while  (  Y  .NE.  0  ) 

.  ASSEHT  (  BUM  .EU.  A  «  (  B  -  Y  )  tANX.  Y  .GE.  0  ) 


WtRlFlCATlUU  CUNEiriCN  SUBROUTINE  TIMES  I  Ai  U<  X  ) 

line  VERIFICAtICi.  CUNOIilUN 

IS  Y  .NE.  U 

A  NO 

18  SU*'  4  A  .EG.  M  •  (  e  .  (  Y  •  1  )  i  .ANli.  Y  -  1  .GE.  0 
ANU 

IS  Y  •  1  .NC.  0 

...........  iMHLltS  -  -  -  -  -  - - 

18  SUM  4  A  ♦  A  .EG.  A«(B*{y«l«l)  )  .AND.  Y  -  1  •  1  .GE.  0 


VCG.PATHs2«2«2  SUBROUTINE  TIMES  I  A«  Bi  X  ) 


CLAUSE 

1 

2 

verification  CCNOItION 

Y  .61.  1 

AND 

•<A*Bi>(A«Y)«  SUM  .£0.  0 

•  ••  AttrLibS 

3 

Y  .OE.  2 

rule 

Y  .GT.  1  s  Y  .GE.  2 

replace 

Y  .6T.  1  «  Y  .GE.  2 

VCG. REPLACE. 


subroutine  times  (  At  Bi  X  I 


PROOF  OF  VERIFICATION  CONDITION  COMPLETED 


VCG>P#TH  =  i2«2<3 


SUBKOUTlNe  TlMtS  t  Ai  Bt  X  ) 


HUE 

PATH  SUUMCE  TEXT 

lb 

kHILE  (  Y  .NL.  0  ) 

Ifc  ( 

n 

.  SUF  s  bUP  ♦  A 

17  i 

1) 

.  Y  s  Y  -  1 

lb  ( 

1) 

.  AbSLHT  (  SUM  .Ew.  A 

19 

ENUkHIcE 

IB 

taHiLC  (  Y  .NL.  0  ) 

21 

final  (  X  tEU.  A  *  a  ) 

Y  )  tAMC.  Y  .GC.  0  ) 


ytRlFlCATXON  CUNCITICN  SliBKOUTlNE  Tlli'e.S  (  A*  Bi  X  I 

Ll(iC  VLHIFICAYICn  CONCiTIUN 

13  t  .NL.  U 

ANU 

le  SOf*  *  A  .EG.  A  •  (  b  -  (  Y  -  1  )  )  ,ANU.  Y  •  1  (GE.  0 
ANU 

13  Y  •  1  .EG.  0 

. —  lUPLltS  - . — — — - — — . 

21  SUM  4  A  .EG.  A  «  a 


vCG,PATHs2i2«9 


SUOKCuYIhE  TXKLS  I  Ai  6|  X  ) 


PROCF  OF  VEKIFICATIOM  COAOITION  COMPLETED 
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VERIFICATION  OF  DIV 


Ccr.lLt.TS  or  F  ILt/CoMf-Ar^C  PRIOR  10  startup  operation 


Nt'A  LIHRARY  =  lEPH. 

S  I  /'■A  I  .LANC-UACt.=  IFlRAt\. 
UA^lU. 

FOl!  ALL  FCLULlS. 
sicuctlhal. 

PHINT.f'CUULt. 

Vtr,.PAfh  =  2tl.2 
W0G.PATh=2*1.3 
VUG*  PATH  =  i!,2,2 
VCGfPAT»-  =  2«2«S 
Ei  C  FOR. 

ENC. 


V0G,PnTh=2ili2 


SUUKuUTIKE  UIV  (  Ai  Bi  0,  R  ) 


LINE 

HAlh  SUUMCL  TEXT 

1 

SUuROUriitE  UlV  (  At 

bt  Ut  R  ) 

lU 

INillAt  (  A  .GE*  0 

.ANC.  U  .6E.  0  ) 

11 

0  =  0 

12 

H  s  A 

13 

aHILE  (  K  .GE.  b  ) 

14  (  1) 

.  ASSERT  (  A  .EG. 

t  •  B  ♦  R  .AKt).  H 

vtRlFlCATlCN  COi.lITICN  SOBRCUT  INE  UI\/  I  A«  bi  b«  R  ) 

LIf.E  VEKIF  KAfiCI,  tONCITlON 

IQ  A  cUl*  u  «At«C«  0  •Ot»  0 

ANU 

13  A  .GE.  U 

...........  iMHLlLS  -  - - 

1<4  A  .Eu.  (  0  •  b  )  4  A  .ANC*  A  .GE.  0 


VOGif  ATh-2tl  i2 


GUUKOUTIKE  DIV  (  At  D«  Oi  R  ) 


PhCuF*  gF  vEtUFlCATlCN  cONClTiON  COhPLtlEu 


StUKCOTlIvE  UlV  <  Bi  0«  R  ) 


Llf  L 

f-Alh  iaUtnCt  rtAl 

1 

bO^HUO  1  li\t  Lit/  4 

A. 

b  t  C  •  H  ) 

lu 

(  A  .OL. 

U 

•  Ari.c.  h  .GC.  0  ) 

11 

(.  =  U 

12 

h  =  A 

13 

v.HlLL  (  h  .GL.  U 

) 

la 

Fli-AL  (  A  .LL.  0 

• 

6  4  R  vAKCi  0  sLC* 

^tMFICATiUK  C«^'-uiTIC\  SiJBI«CUTll\£  UlV  (  A<  B«  0.  R  ) 

Lll.t.  VLRlFKATlQr.  CCNCIiIOK 

10  A  .(,£•  IJ  •AkO<  B  0 

Af.U 

13  A  .lT.  t 

IhFLIES 

la  A  (  0  «  B  )  «  A  .Ah,c«  0  .LC*  A  tANC*  A  .LT.  B 


v(.u.F>AThs2«l«3  SUBI«CUT1KC  Ulv  I  A.  B.  0,  R  ) 

Pt.CCF  OF  VEHIFICATION  C0^C1T10K  tOKFLETEO 


VCC,  rATFA2«2«2  SUBKOOTINE  Uli/  (  a.  e.  0.  R  ) 


Llf.L 

K/<I4i  bLLHLL  TEXT 

13 

khlLL  4  h  .6t.  R  ) 

( 

1) 

.  AB3LKT  (  A  .Lw. 

U  •  b 

♦  R 

.AMI.  R 

.GE. 

0  1 

15 

( 

1) 

.  (.  s  1.  «  1 

Ife 

4 

1) 

.  R  s  n  •  B 

17 

c.r<Lii<HlLE 

13 

fthlLt  4  K  .GE.  B  ) 

14 

( 

1) 

.  ABSLKT  (  A  .EL. 

U  *  B 

♦  R 

.ANU.  R 

.GE. 

0  ) 
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VtfUf  ICiM  Iti.  Lt-I-L  i  T  Kl.  SUliitCOnKE  OIV  (  »•  B.  C,  R  ) 

LII.E  IC^iTlON  CONLlllOl^ 

13  K  .OL.  b 

ANlJ 

l^  A  (  U  «  u  )  ♦  H  <AwC«  h  .(lE.  0 

AloLi 

13  R  -  b  .fcC.  b 

- - -  Ihi^LlLS - - - - - - - - 

14  A  .L>.«  ((4«ll*e>-»R*8  .AtiU.  H  -  B  .GC.  0 


</CGi  FATP  =  ^i2ib  SGbKCoTlNL  DlV  (  Ai  bi  U.  R  ) 

FnOCF  CF  VEKIFICAIICN  CCl\ClTIOri  tt'MPLETCb 

r- 

-  a:  • «:  1  i 

SGbKOUl INL  DIV  (  m.  Bi  Di  R  ) 

tr  1 

FAIP  iCCt»L».  1t*1 

•  t 

1  4* 

^.hiLL  (  K  .GL.  b  ) 

.4  ( 

1) 

.  ASSLIxT  (  A  .£u.  6  »  e  T  K  .aNU*  H  .GE.  0  > 

It  ( 

1) 

.  G  =  G  ♦  1 

16  ( 

1) 

.  M  s  h  «  B 

17 

LNLir.H  iLb 

13 

ikHiLE  <  R  .GL.  B  ) 

IS 

FXivAL  (  A  .LG.  ti  •  B  4  R  .and.  U  .LE.  H  .AND.  R  .LT.  B  t 

VLRiriCATlUu  CC^C;ITIC^  SUbKCbTIlvC  DiV  (  At  e«  U«  R  ) 


Lli.L  ICATlbl,  CCNCilltA 

13  R  .GL.  lb 

ARC 

14  A  .tu.  (  a  *  u  )  t  H  •Al-tD«  K  (GE*  0 

AhU 

13  R  -  o  .LT.  0 

- - -  Implies  - - — — — - - - - - — 

le  A  .LG.  (  .AND.  0  .LE.  R  -  B  .AND.  R  •  B  .LT.  B 


■vLGif  J 


SUBkOUlIt.t  UlV  (  A*  Bi  Ot  R  ) 


PRCCF  of  VEBlFlCAllOh  COtvOniCN  COHMLETtO 


VERIFICATION  OF  BINSCH 


CCnUMS  of  F  ILt:/COWf'ANO  PRI08  TO  SlAKTUP  CPERATiON 


SlAHT,LAf.GUAGE  =  lFTRAN, 

L=ASlC. 

.''t[.LLC  =  (FlMi)CH)  , 

SU-lCTURAL. 

pHiM  .ncoule;. 

FlLtf  ANE  .L0G=0UTPI/T. 

VLGiPATh-^<l'2 
UtG.PAI}.  =  2.1.J 
VtGfPATF"*  iJtO 
VtGtPATH=2«3*9 
VtG. replace. 

EHPCR  =  .TRUE. 

•  tfX. 

UtG.PATH=2«3«9 
VUG, replace. 

E"FCK  =  .false. 

*tf;C. 

VCG«PATti=3<2«H«2 
VCGiAXXCF  • 

PAT  .LT.  0  &  PXl  .LT.  -1  .OR.  PXl  .CO.  •! 

«thC. 

vCG.AXIcF. 

PAl  .If^p.  p<2  .OR.  PX3  *  (PXI  .IKP.  PX2»  .OR.  «Pxl  .ImP.  Px3) 

•  tfjC . 

vCG«PATHsR.2»5.6»2 
VUG. replace. 

PAl  .LT.  0  s  PXl  .LE.  -1 

*tf,c. 

VCG. replace, 

PAI  .ANC.  PX2  .LT.  •!  .IPP.  PX2  «LC.  -1  .AND.  PX3  * 

PAl  .ARE.  PX2  .LT.  -1  .IPP.  PX3 

*tNC.  ) 

VLG. replace. 

PXl  ♦  PX2  .LC.  0  *  -  PXl  -PXP  .CE.  0 
*tK'C. 

vtc, replace. 

PXl  .gE.  0  2  PXl  .GT*  0  .OR.  PXl  .EO.  0 

V(>G.Axl0F  i2. 

VLG.PATH*'*,2i5,7i2 

VCC.PATPS3.21H.3 

VIG«AXX0R. 

-C1AI4RJ/2I  ♦  H  ,GE,  -1  *  -N*p  ,GE.  -2 

•  tf,C. 

y,CG,AxlOP. 

PXl  .LT.  -I  *  PXl  ,LE.  -2 

•  tfiC. 

VLG, replace. 

•A  «  R  .LE.  >2  .ANO.  PXl  .AND.  -N  «  M  .GE.  <>2  « 

•N  t  ¥  .EC.  -2  .ANO.  PXl 

VCG, replace. 
fj  =  r'*2 

•  tMC. 

VLG.REPlACE. 

(12  ♦  R  ♦  M)/2)  *  Rtx 

•lnc  . 

VLG«PATHB*«i2i9iGt3 

VLGiRCPlACE. 

>N  *  ((N4M)/2|  .CEt  -1  ■ 

-N  ♦  M  .Ct.  -2 


D-26 


Vl.G.flxlCf'*'*. 

V<.r.,UCPL<'CE. 

t.  =  K  +  i 

•  tr  L . 

\i^C  .REf'L/'CE, 

(  ♦  i*.  ♦  M)/2)  =  H  +  X 

*tMC . 

VI.G.REHL<*CL. 

-X  ♦  AKRflt  ((  l  +  .Lt.  0  = 

X-AHKAYl  (l^KM  .GT.  0  .OR.  X-ARRAY  (ll'frt))  CU.  t) 

*LNC. 

VL(:.AXiOV*2, 

\)tGtRATRs**«2«b*7»3 

vCG.RERlACE. 

X  =  array  ( (R+N)/2) 

•  Lf.C. 

vgg. replace. 

SCPTECIARRAYiLENGTHIs  (ARRAY(l)  -  AKRAYOlt  .LT.  0  )  .AND.  (I  .6C.  1) 
.A^C.  (I  .LT.  LENGTH) 

•  tf'C. 

VCG. replace. 

I  (R'»n)/2 

•  tho. 

ENC. 


VC6«PATHs2«1«2  SUftKOUTINE  UlNStCH  I  ARRAYi  LENGTH.  X.  LOOKUP.  ERROR  ) 


line  path  SOuRCt  TEXT 


I 

It 

16 

17 

le 

19 

20  (  1) 


bULHCLTiKE  UINSCH  (  ARRAY.  LLNi.Th.  X.  LOOKUP.  ERROR  > 
initial  (  1  «LT.  LtNGIH  .AUU.  sCrTEO  I  ARRAY.  LENGTH  )  .AND.  ( 

«AI.RAY  (  1  )  .LE.  X  .ANU.  X  .LT.  ARRAY  (  LENGTH  )  )  ) 

K  s  1 

N  s  length 

ERROR  s  .FALSE. 

nHILE  (  K  4  1  .LT.  N  > 

.  ASSERT  I  M  .LT.  N  .and.  SORTED  (  ARRAY.  LENGTH  )  )  .AND.  (  ( 

•.  array  (  M  )  .LE.  X  .AND.  X  .LT.  ARRAY  (  N  )  )  .AND.  .NOT.  fRHOR  ) 
*.  ) 


verification  CUNCITKn  SObROUTiNE  blNSCH  (  AKKAy.  LENGTH.  X.  LOOKUP.  ERROR  ) 

LINE  verification  CONCITION 

IS  1  .LT.  length  .ANu.  SORTED  (  ARRAY  .  LLNGiH  >  .ANO.  ARRAY  (  1  >  .Lf.  X 
.ANU.  X  .LT.  array  (  LENGTH  ) 

AND 

19  1  f  1  .LT.  length 

-  IMPLIES  . . . . — . — 

1  .LT.  LENGTH  .ANu.  SORTED  (  ARRAY  ,  LENGTH  )  .ARC.  ARRAY  (  1  )  .LF.  X 
.AND*  X  .LT.  ARRAY  (  LENGTH  )  .AND.  .NOT.  .FALSE. 


20 


VtC.PflTH=2.1i2 


SUbRrjUTlNL  BlNSCH  (  ARHAYi  LLNGTHt  X<  LOOKUP*  ERROR  ) 


proof  of  verification  cuKCXTioN  completed 


VCG.rATH=2.it3 


SUHROUTIRE  HINiiCH  I  ARRAYi  LLN&THt  Xt  LOOKUP*  ERROR  ) 


LK.t 

PATH  iOUHLL  lt;XT 

1 

SUuHOUTiNE  biKSCH  (  ARRAY*  LENGTH*  X* 

LOUKL'P*  ERROR  1 

IS 

initial  I  I  .LT.  LLNGTh  .ANU.  SORTED  i 

1  array*  length  )  .and.  ( 

•ARRAY  (  1  I  .lE.  X  .AND.  X  .LT.  ARRAY 

(  LLNGTH  1  1  ) 

Ifa 

F  =  I 

17 

N  s  LEnGIH 

16 

LRROR  =  .FALSE. 

19 

WHILE  I  M  •  I  .LT.  N  I 

32 

ASSERT  (  (  M  .LT.  N  .AND.  SGRTeC  (  ARRAY*  LENGTH  1  1  .AnD.  (  ( 

•AHRAT  (  ¥  )  .lC*  X  .ARC*  X  .LT.  ARRAY  (  N  )  >  tAND*  •NOT*  ERROR  ) 

•  ) 


verification  CONLITION  SObROUTlNE  BINSCH  (  ARRAY.  LENGTH.  X*  LOOKUP.  ERROR  ) 

line  verification  concition 

IS  I  .LI.  length  .AKU.  SCRTEU  (  ARRAY  .  LENGTH  )  .ANC.  ARRAY  (  1  )  .LF.  X 
.AijU.  X  .LT.  array  (  length  ) 

AND 

IS  1  «  1  .60.  length 

— - . IMPLIES . . . — — — — — . .  .  . . 

32  1  .LT.  LENGTH  .AND.  SORTED  (  ARRAY  •  LENGTH  )  .ANC.  ARRAY  (  1  )  .LF.  X 

.AND*  X  .LT.  ARRAY  (  LENGTH  )  .AND.  .nOT.  .FALSE. 


VCG*PAThs2*1*3 


SUBROUTINE  BInSCH  I  ARRAY*  LENGTH*  X*  LOOKUP*  ERROR  I 


PROOF  OF  VERIFICATION  CONDITION  COMPLETED 


VLG*PATps2*3«a 


subroutine  BINSCH  (  array*  LENGTH,  Xt  LOOKUP*  ERROR  I 


LINE 


PATH  SOURCE  TEXT 


19 

32 


33 

3a  (  II 


WHILE  (  M  *  1  .LT.  N  I 

assert  I  I  M  .LT.  N  .and.  SURTED  I  ARRAY*  LENGTH  I  I  .Ar.D.  (  ( 
*ARRAY  (  M  I  .LE.  X  .AKi;;.  X  .LT.  ARRAY  I  N  )  >  .AND.  .NOT.  ERROR  I 

•  I 

IF  I  X  .NC.  array  (Mil 

.  FINAL  (  .NOT.  ERROR  .AND*  X  .EC.  ARRAY  I  LOOKUP  I  .OR.  ERROR  I 


D-28 


VtRlFICATION  CUNCITION 


SUUKOuTlN£  BIN^CH  I  ARKAy,  UCNGTHt  Xi  LOOKuPi  CRROH  ) 


( 


line:  VIKII  ICATK^N  CUNUlTiON 

19  R  1  .GE.  N 

AND 

32  R  .LT<  N  ’AhO.  SOKTEC  (  ARRAY  •  LENGTH  )  .AnC*  ArkAY  (  H  )  .LE>  X  .AND 
.  X  .LT.  array  (  N  )  tANCt  .NOT.  ERROR 

ANO 

33  X  .NL.  array  (  H  > 

.  IMPLIES . . . - . 

38  (  .NOT.  .TRUE.  .and.  X  .£0.  ARRAY  (  LOOKUP  )  )  .UR.  .TRUE. 


VLG«PATh=2«3iG 


SUbHOUTiNC  OINSCH  (  ARRAY.  LENGTH.  X.  LOCKiiP.  ERROR  I 


PROOF  OF  verification  COROITION  COHPLLTEU 


VtG.PAThs2«3«9  SUURQUTIfvE  blNbCH  (  ARRAY.  LENGTH.  X.  LOOKiiP,  ERROR  ) 

line  path  source  TEXT 

19  AHiLE  (  K  «  1  .LT.  N  > 

32  ASgERT  (  (  H  .LT.  N  .ANU.  SORTkO  (  ARRAY.  LLNGTH  >  >  .ANO.  (  ( 
*AKRAY  (  P,  )  .LE.  X  .ANC.  X  .LT.  ARRAY  (  N  )  )  .ANO.  .NOT*  ERROR  ) 

•  I 

33  IF  <  X  .NE.  ARKAY  (HI) 

36  FINAL  (  .NOT.  ERROR  .ANC.  X  .Eu.  ARRAY  I  LOOKUP  )  .OR.  FRROR  ) 


VLRIFILATIUN  CUNLlTlCN  SUUROUTINL  BlNSCH  (  ARRAY.  LENGTH.  X.  LOOKUP.  ERROR  > 

line  VERIF ICATION  CONCITION 
19  M  4  1  .GE.  N 
ANO 

32  K  .LT.  N  .ANC.  SORTED  (  ARRAY  «  uENGTh  t  .AnC.  ARRAY  (  M  )  .LE.  X  .AnO 
•  X  .LT.  ARRAY  (  N  )  .AND*  .NOT.  E'RROR 

AND 

33  X  .EG.  array  (  R  ) 

— - -  IKPLIES  ——————— - - - 

36  (  .NOT*  ERROR  .AND.  X  .EO.  ARKAY  (  R  >  )  .OR.  ERROR 


D-29 


*«•  «- 


VLG.PflTHs2.itli 


SUUKOUTlNt  blNSCH  (  ARHAT.  LLNGTH.  X.  LOOKliP.  r.RROH  I 


clause  VLRlPlCflTlCN  CUNClTlON 

1  X  -  ARRAY  (  N  )  .LTt  0 

ANU 

2  .NCI.  EHRQH 

ANU 

3  SCKTLO  (  ARRAY  .  LENGTH  ) 

ANL 

4  X  -  ARRAY  <  M  )  .EO.  0 

AND 

5  «N>R.6E.  “1 

uNC 

A  •M'fR.LT.O 

aNL 

i  •  X  *  array  (  R  I  .LE.  0 

. . . 

a  ERROR  .CR.  (  «NOT<  ERROR  .AnO*  X  •  ARRAY  (  M  )  *£0.  0  ) 
enterel  expression 
ERROR  *  .TRUE. 

RULE  ERROR  *  .TRUE. 

replace  Error  s  .true, 

replace  error  s  .true, 

replace  Error  •  .true. 

VLG.REPlACE.  SUOROUTINE  BlNSCH  (  ARRAY.  LENGTH.  X.  LOOKiiP,  ERROR  > 

PROCF  OF  VERIFICATION  CONOITION  COMPLETEO 


D-30 


- 


VtG«PATH  =  <:*3«y 


SUyHOuTlt'.E  falNSCH  {  ARUAy,  LENGTH,  X,  LOOKiiP,  ERROR  ) 


LINE 

RAIH  SOURCE  TEXT 

19 

..UiLE  ( 

R  ♦  1  .LT.  N 

) 

32 

ASSERT 

(  (  K  .LT.  U 

./iNC. 

♦ARRAY  ( 

R  )  .lE .  X  . 

AUU  . 

♦  ) 

33 

IF  (  X 

.NE.  ARRAY  ( 

K  )  ) 

36 

FIuAL  I 

•NOT.  ERROR 

.  AND  . 

SLRTtO  (  array,  length  ) 
X  tLT.  array  (  N  )  )  •AND 


%  •Eu.  array  I  LOOKUP  ) 


verification  CONLITION  S^UROUTINt  OUSCH  (  ARRAY,  LLNGTH,  X, 

LINE  VERiriCATlON  CONCITION 

15  M  ♦  1  .GE.  N 

ANU 

32  K  .LT.  N  .ANO.  SORTED  t  ARRAY  ,  Ll-NGlH  )  .AND.  ARRAY  (  K 
,  X  ,L1.  ARRAY  (  U  )  .ANC.  .NUT.  ERROR 

and 

33  X  .Lfi.  array  '  n  I 

...........  IrPLIES  —  —  -  — 

38  (  •NOT.  error  .and*  X  .EO*  ARRAY  IK))  .OR.  ERROR 


) 


)  .AnD.  (  ( 

.  .NOT.  ERROR  ) 

.OR.  fRROR  ) 

LOOKUP,  ERROR  I 

)  .le.  X  .And 


VtGfFflTH  =  i:'3«9 


SUbKOUTlNC  <  ARhAYf  LENgTHi  Xi  LOOKUP.  cRrCR  I 


CLAUSE  VERIFICATION  CONDITION 

1  X  -  ARRAY  (  N  )  .LT.  0 

AND 

2  .NOT.  ERROR 

ANO 

3  SORTED  (  ARRAY  •  LENGTH  ) 

AND 

<«  X  -  ARRAY  (  M  )  .EG.  Q 
AND 

5  -  N  ♦  R  .GE.  -X 

ANO 

G  -  N  ♦  R  .LT.  0 

and 

7  -  X  «  ARRAY  (  R  )  .LE.  0 

...........  implies . —  . . 

e  ERROR  .OR.  I  .NOT*  ERROR  .AND.  X  -  ARRAY  (  H  >  .EO.  0  ) 

cntcreu  expression 
ERROR  *  .false. 

rule  error  z  .false, 

replace  error  ■  .false, 

replace  error  z  .false, 

replace  error  *  .false. 

vCC.REPLACE.  SUbROUTlNE  BInSCH  I  ARRAY.  LENGTH.  X.  LOOKUP.  ERROR  ) 

proof  of  VERIFXCATXON  CONDITION  COMPLETED 


SUCJKOUTlI'.t  BlNSCH  (  ARKAYi  LtKGTHt  Xi  LOOKllPi  £RRCR  ) 


\((-G.PATIi=3i2«<«i2 


LIfiE 

F'ATti  SOURCE  Text 

19 

LHiLE  (  X  i  1  .LT.  N  ) 

20 

( 

1) 

.  ASSERT  (  1  R  .LT.  N  .AWCj.  SORTED  (  ARRAY, 

length  ) 

)  .AND,  (  ( 

*,  ARRAY  (  K  )  .LF*  X  .AND.  X  .LT.  ARRAY  (  N 
*.  ) 

.  1  =  (  X  ♦  N  !  /  2 

)  )  .AND. 

.NOT.  ERROR 

21 

( 

1) 

22 

( 

1) 

.  IF  (  x  .LT.  ARRAY  (  I  )  ) 

23 

1 

2) 

.  .  14  =  1 

30 

( 

1) 

.  ENCIF 

31 

ENumHIlE 

19 

NKILE  1X41  «LT.  N  ) 

20 

( 

11 

.  ASSERT  (  (  R  .LT.  N  .AND.  SORTED  1  ARRAY, 

length  ) 

>  .AND.  (  ( 

«.  ARRAY  (  M  )  .LE.  X  .AnO.  X  .Li.  ARRAY  (  N 

)  )  .AND. 

•NOT.  ERROR 

*  •  ) 


ft 


VLRIPICATIUN  CONClTICr,  SUBRCUTIaC  BltjSCH  (  array,  LtNGTh,  X,  LOOKUP,  LRROH  ) 

LINE  verification  CONOITION 

19  M  ♦  1  •LT*  N 

ANC 

20  H  .LT<  K  •ANO.  SORTED  (  ARRAY  ,  LENGTH  >  .AhD>  ARRAY  (  M  )  .LE<  X  .AND 
t  X  .LT,  array  (  N  i  .ANC.  .NUT.  ERROR 

and 

22  X  .LT.  array  (  (  R  ♦  N  I  /  2  ) 

ANL 

19  R  ♦  I  .LT.  (  R  ♦  N  »  /  2 

...........  iRPLUs  — — — — — . . . . 

20  M  •LTx  (  R  +  N  I  /  2  .ANO*  SORTED  (  ARRAY  ,  LENCTR  I  .AND.  ARRAY  (  M  ) 

.LE.  X  .AND*  X  .LT.  ARRAY  (  (  R  ♦  N  )  /  2  )  .ANc.  .NOT.  ERROR 


VCG.FATh=3t2t4.2  SUBKOOTIKE  BIMSCH  i  A«HAY.  LENGTH.  X.  LOOKUP,  ERROR  ) 

CLAUSE  verification  CONDITION 

1  X  -  ARRAY  (  N  »  .LT.  0 

AND 

2  .NOT.  ERROR 

AND 

3  SORTED  (  array  .  LENGTH  I 

AND 

it  X  -  ARRAY  i  (  N  «  R  )  /  2  I  .LT.  0 
AND 

5  -  N  >  R  .LT.  -1 

AND 

6  -  X  ♦  ARRAY  (  K  )  .LE.  0 

and 

7  -((N*R)/2)4K  .LT.  -i 

- . IKPLIES . — . - . — 

9  -<(N*RI/2)*R  .LT.  0 

ehterel  expression 

Pxl  .LT.  0  S  PXl  .LT.  *>  1  .OR.  PXl  .Eb*  •  I 
RULE  PXl  .LI.  0  *  (  PXl  .LT,  -1  .OR.  PXl  -1  ) 

replace  X  -  ARRAY  T  N  »  .LT*  0  *  <  X  -  ARRAY  <  N  )  .LT*  -1  .OR,  X  -  ARRAY  I  N 

)  .EG.  -1  I 

replace  X  -  ARRAY  i  (  N  ♦  R  »  /  2  »  .LT,  0  c  I  X  -  ARRAY  I  (  N  ♦  H  »  /  2  >  .LT 

.  >1  .CR.  X  •  array  (  <  N  ♦  M  )  /  2  >  *EO.  -1  ) 

replace  -<  IN+P>/2)+R  ,LT,  0«-<  (N+M)/2)*M  ,LT,  -I  .oR, 
-I  TN»P»/2JtR  .EQ.  -1 


Saved  as  axiom  i 


VCGiAXlC''*  SUUKGUTIUC  bIMSCH  I  ARRAY*  LENGTH*  X*  LOOKUP*  ePROR  ) 

CLALSL  VERUICATICN  CONOXTION 

1  (  X  -  ARRAY  I  N  I  .LT*  *1  .OH.  X  -  ARRAY  (  N  )  .EC.  -1  > 

AND 

2  •HOI.  LHHOH 

ANO 

3  SOHTLC  (  ARRAY  *  LENGTH  ) 

ANU 

4  I  X  -  ARRAY  <  (  N  ♦  M  )  /  2  )  .LT.  -1  .OR.  X  -  ARRAY  J  I  N  ♦  K  )  /  2  ) 

•LU.  *1  ) 

ANO 

5  -  N  ♦  R  .LT.  -i 

ANU 

G  -  X  ♦  ARRAT  «  R  J  .LE.  0 
ANO 

7  -<(N*R)/2»>R  .LT.  -I 

. —  iKfLiES . — - - - — . — — 

e  •((N4R)/2)«M  .LT.  >1  .OR.  .(  (N4R)/2)«M  .CO.  .1 

entcrec  expression 

Pxl  .IRP.  PX2  .OR.  FX3  =  C  PXi  .IRP,  PX2  )  .OR.  (  PXi  .JRP.  PX3  ) 

RlLC  (  Pxi  'IMP*  Px2  .OR.  PX3  )  c  f  (  Pxl  .IRP.  Px2  >  .OR.  I  PXl  .IMP.  PX3 

)  ) 

RtPLACE  (  (  X  -  ARRAT  <  N  )  .LT.  -I  ,OR.  X  -  ARRAY  (  N  »  .EO,  -1  )  .AND.  ,nOY. 

ERROR  .ANO.  sorted  (  ARRAY  *  LENGtH  )  .AnD.  (  X  •  ARRAY  (  (  N  ♦  M  )  / 

2  I  .LT.  -1  .CR.  X  -  array  (  (  N  ♦  r  )  /  2  )  .E«.  -X  )  .AnD.  -  N  ♦  M 

.lT,  -1  .ANC.  -  X  ♦  ARRAY  i  R  )  .LE.  U  .AhD.  -<  IN«R)/2)«R. 

LT.  -1  .IRP.  -«  «N*M>/2J*R  ,LT.  -J  .or,  -  (  I  N  ♦  M  )  /  ?  ) 

♦  R  .EG.  •!  )  s  (  (  (  X  -  ARRAY  «  N  »  .LT.  -1  .OR.  X  -  ARRAY  (  N  )  .Cfi 

.  -X  >  .and,  .not.  error  .and.  sorted  {  array  *  LENGTH  )  .AND.  <  X  -  A 

RRAY  (  I  N  t  N  )  /  2  )  .LT.  -1  .OR.  X  -  ARRAY  »  C  N  ♦  K  )  /  2  )  .Ee.  » 

X  I  .AND.  -  N  «  M  .LT.  >X  .AND.  •  X  «  ARRAY  I  R  )  .LE.  0  .AND.  •  (  (  N 

♦  R  )  /  2  I  4  M  .LT.  -X  .IMP.  •((N4M)/2)«M  ,LT.  -1  »  .OR. 

(  (  X  -  ARRAT  (  N  )  .LT.  -X  .OR.  X 
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SAVED  AS  AXICI^  2 


VCG.AX1C^•  SUBRCUTlKL  BlNSCH  I  ARHAv,  LLASTHt  X«  LOOKiiPi  tRROH  > 

PROCF  OF  VEHIFICaTICN  CCADXTION  COMPLETED 
USir<G  THL  FULLObtlNl*  AXIOMS  i  2 


VCG.PATh=4(2iS«6i2  SUUROUTINL  DlUsCH  I  ARKAt«  LENGTHi  X«  LOOKiiPi  ERROR  ) 


LINE 

PATH  SOURCE  TEXT 

19 

n»ULL  (  M  .  1  .LT.  N 

> 

20 

( 

1) 

.  assert  (  <  H  .LI. 
*.  ARRAY  (  R  1  .LE. 

•.  > 

.  I  =  (  M  ♦  N  )  /  2 

N  .AND.  Sorted  (  array,  length  >  >  .and.  (  i 

X  .AND.  X  .lt.  array  I  N  >  >  .AND.  .NOT.  ERROR 

2X 

( 

1) 

22 

t 

X) 

.  IF  (  X  .LT.  ARRAY 

<  I  1  t 

24 

OKIF  ‘  X  .GT.  array 

(II) 

25 

< 

X) 

.  M  =  I 

3U 

ENOIF 

2X 

ENomHIlE 

X9 

mHILE  (  M  ♦  X  .LT.  N 

I 

20 

ASSERT  (  I  R  .LT.  N 

.AND.  SORTED  1  ARRAY.  LENGTH  I  I  .AnD,  (  ( 

«ARHAy  (  t>  )  iLCi  X  iAmO*  X  •LT.  AHRAT  C  N  >  )  lAMO.  iNOt*  ERROR  > 

•  » 


VERIFICATION  CONLXTlON  SUBROUTINE  BlNSCH  (  ARKAy,  LENGTHi  Xi  LOOKuPi  ERROR  > 

LINE  verification  CONDITION 

XI  R  »  X  .LT.  N 

AND 

20  R  .LT.  N  .AND.  SORTED  (  ARRAy  •  LENGTH  *  .AND.  ArkAT  (  R  )  .LE.  X  .AND 

.  X  .lt.  array  (  N  )  .And.  .not.  error 
AND 

22  X  .6E.  array  (  I  R  *  N  )  r'  2  I 
AND 

24  X  .GT.  array  (  (  R  4  N  )  /  2  ) 

ANC 

X9  (  (  H  «  N  I  /  2  I  «  X  .lt.  N 

. - . - . — — — — - - — — . . 

20  (  R  ♦  N  )  /  2  .lt.  N  .and.  SOHTCC  (  ARRAY  ,  lCA^TH  )  .AND.  ARRAY  (  (  R 

♦  N  )  /  2  )  .LE.  X  .AND.  X  .LT.  ARRAY  (  N  |  .AND.  .NOT.  ERROR 


D-36 


SUUKOOrihC  B1»SCH  (  ARHAY,  LCNGTHi  X,  LOOKUP,  ERROR  > 


VCG,PATH=H,i’,3,G,<! 

CLAUSE  VEKIFICATICU  CONCITICN 

1  X  -  array  (  N  i  •LT.  0 

ANU 

2  .KOI.  ERROR 

ANO 

3  SCHfLC  <  ARRAY  .  LENGTH  ) 

ANU 

4  X  -  array  (  (  N  ♦  H  >  /  2  I  .GT.  0 

ANU 

5  -  N  ♦  R  .LT.  -1 

ANU 

«  <■  X  4  ARRAY  (  F.  I  .LE.  (I 

ANU 

7  -N4((N*F)/2)  .LT.  -1 

— . IRPLIES  —————————  — . . 

a  -N4<(N«F)/2)  .LT.  0 

AND 

a  •  X  4  AnRAY  (  (  N  4  F  }  /  2  )  .LC.  (I 

i 

entereu  expressiun 

PXl  .lT.  0  S  PXl  .lE.  -  1 
RULE  Pxl  .LT.  0  s  PXl  .LE.  •! 

replace  X  •  ARHAY  (  N  )  .LT.  0  s  X  •  ARRAY  t  N  >  .LE. 

REPLACE  -N4I  (N4F)/2}  .LT.  0>-N4llN«H|/2)  .LE.  -1 
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%  A/Y*- 


\ 


VtO<(<CPLAC£.  SObHOUTIM'  bIN&CH  t  AHHAITi  LtNGTHt  X«  LOOKUP*  LRPCh  > 

CLALSE  VERIUCATICN  tCNCniON 

1  X  -  ARkAY  (  N  I  •££*  *1 

ANO 

2  •KOI.  ERROR 

ANU 

3  SUHTEO  (  array  <  LEKGTH  ) 

AKU 

H  A  •  ARRAY  (  (  K  «  M  )  /  2  )  .6T.  0 
fitiu 

5  -  N  ♦  R  .LT.  -1 

aku 

6  -At  ARRAY  (  R  )  .LE.  0 

AKl 

7  -rj4((N4R)/2)  ,LT.  -1 

...........  iRPLltS 

e  .N4(«R4r»/2)  .le.  -1 

anl 

S  -  X  ♦  array  «  (  N  4  M  )  /  2  )  .le.  0 
enteReg  expression 

Pxl  .ANC.  Px2  .LT.  *  1  .IRP.  PX2  .LE.  •  1  .AND.  Px3  s  PXl  .AND.  PXP  .LJ.  >  1 
P.  PX3 

RELE  (  PXX  .AND.  PX2  .LT.  *1  .IMP.  PX2  .LE.  .ANO.  Pa5  i  s  (  PXl  .AND.  PX 

2  .LT.  -I  .IMP.  PX3  ) 

replace  (  X  •  array  (  N  )  .le.  -1  .ANL.  .NOT.  ERROR  .ANC.  SORTED  I  ARRAY  •  LLN 

CTH  )  .AND.  X  -  ARRAY  <  <  N  4  R  )  /  2  )  .GT,  0  .AND.  -  N  4  R  ,LT,  -I  . 

ANO.  -  X  4  ARRAY  (  R  )  .LE.  0  *ANC.  «N4(  (N4R)/2)  .LT.  >1  .1 

MP.  -N4<(N4R)/2)  .le.  •!  .ANC.  •  X  4  array  (  (  N  4  R  )  /  2 

)  .LE.  0  )  s  I  X  •  ARRAY  (  N  )  .LE.  «1  .AnC.  .NOT.  ERROR  .ANO.  SORTED 

(  ARRAY  «  length  I  .ANO.  X  -  ARRAY  (  <  N  4  M  >  /  2  >  .6T.  0  *AnO.  .  N 

4  M  .LT.  -1  .ANO.  -  X  4  array  (  R  )  .LE.  0  .ANO.  -N4(  (N4R)/2 

)  .LT.  -X  .IMP.  •  X  4  array  (  (  N  4  M  >  /  2  >  .LE.  0  ) 


•  IM 
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VtG. replace 


SUBROUTINE  BlNSCH  (  ARRAY  •  LLNGTHf  X«  LOOKUP,  ERROR  ) 


clause  VCRIPlCATlCN  CONCillON 

1  X  -  array  I  N  )  .LE*  -X 

ANO 

2  •NOT.  EHRUH 

ANU 

3  SCRTLC  (  ARRAY  ,  LENGTH  ) 

ANO 

^  X  -  array  <  (  N  «  R  )  /  2  )  .CT.  0 

ANO 

5  -  N  ♦  R  ,LT.  -1 

ANO 

6  >  X  4  ARRAY  (  R  I  .LE,  0 

ANU 

7  -N4<(N4M»/2»  .LT.  -1 

.  IMPLIES  . 

a  -  X  ♦  array  (  «  N  4  p  I  /  2  >  ,l£.  0 
ENTERED  EXPRESSION 

Pxl  ♦  P*2  ,LE,  0  a  -  PXi  *  Px2  ,6C,  0 

RULE  Pxl  ♦  PX2  .LE*  0  a  -  PXX  -  PX2  .6E.  0 

replace  -  X  ♦  ARRAY  <  M  >  .LE.  0  a  -  -  x  -  ARRAY  C 

RtPLACE  -  X  4  ARRAY  (  (  N  4  M  )  /  2  )  .LE.  0  a  •  - 

•  Gt*  0 


)  .GE.  0 

-  array  «  I  N  4  M  )  /  2  ) 
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VCCiREPlACE 


SUtJKOUTIUt  BlNSCH  i  ARKAy,  LENGTHt  X.  LOOKUP.  ERROR  > 


CLAtSE  VERlFICATlOr,  CONDITION 

1  X  -  ARRAY  (  N  )  .LE.  “1 

AND 

2  .tsOT.  ERROR 

AND 

3  sen tLD  (  ARRAY  «  LENGTH  J 

and 

^  X  -  ARRAY  (  <  N  ■»  M  )  /  2  )  .tiT.  0 
AND 

5  -  N  ♦  A  ,LT.  -1 

AND 

£  X  -  ARRAY  (  M  )  .bE.  0 
AND 

7  -N.((N4R)/2)  ,LT.  -i 

...........  iRPLltS  .  . . . 

e  X  •  ARRAY  (  I  N  4  K  )  /  2  )  .6E.  0 
CNTCRiD  EXPRESSION 

PXl  .GE.  0  3  PXI  .GT.  0  .OR.  PXI  .EG.  U 
RLLE  PXI  .GE.  0  3  (  PXI  .GT.  0  •OR.  PXl  .EO.  0  ) 

replace  *  -  array  i  M  »  .GE*  0  »  I  X  -  ARRAY  (  R  »  .GT.  (J  .OR.  X  -  ARRAY 
.EC.  C  ) 

REPLACE  X  -  ARRAY  (  (  N  4  R  »  /  2  I  .GE.  0  «  X  -  ARRAY  '*  »  N  4  M  )  /  2  ) 
0  .OR.  X  •  ARRAY  (  (  N  4  M  )  /  2  )  .EO.  0 
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I'-* 


I  H  ) 

•  liT  • 


««*  **• 


I  vt-G.neHLACL.  SUbXOUTlNC  BlNSCH  (  AHHAYi  tCNbTH.  X«  LOOKiiPt  tRRCH  ) 

CLAliSC  VLHlFlCATlCN  CONDITION 

1  X  -  ARHAY  (  N  )  .LE.  ~l 

AND 

2  tNCT.  ERROR 

AND 

3  SORTCO  (  array  «  length  ) 

AND 

4  X  -  ARRAY  (  «  N  •»  R  >  /  2  )  .bT.  0 

AND 

5  -  N  ♦  R  .LT.  -1 

AND 

6  (  X  -  ARRAY  1  M  )  .6T.  0  .OR.  X  •  ARRAY  (  R  )  .Co.  0  ) 

AND 

7  -N*<<N*R)/2»  .LT.  -1 

. — —  iRHLltS . - . — - — . 

o  a  X  •  ARRAY  (  (  N  «  R  )  /  2  )  .GT.  0  .OR.  X  •  ARRAY  (  C  N  ♦  M  >  /  2  I  .C 

0.  0 

USING  AXIOH  2 

RULE  <  Pxl  .IRP.  PX2  .OR.  PX3  >  s  (  (  PXl  .IRP.  PX2  )  .OR.  I  PXl  .IRP.  PX3 

I  I 

replace  (  X  -  ARRAY  (  N  )  .LE.  -1  .AND.  .NOT.  ERROR  .AND.  SORTED  C  ARRAY  i  LEN 

gth  )  .and.  X  •  Array  (  (  N  ♦  r  )  /  2  >  .gt.  0  .and.  •  n  ♦  m  .lt.  .1  . 

AND.  (  X  -  array  (  R  )  .GT.  0  .OR.  X  -  ARRAY  (  R  I  .EO.  0  >  .AND.  -  N 

«  (  I  N  t  R  )  /  2  )  .LT.  >1  .IRP.  X  •  ARRaT  I  (  N  R  I  /  2  )  .GT.  0  . 

OR.  X  -  array  (  I  N  «  R  )  /  2  )  .EO.  0  I  s  I  <  A  -  ARRAY  C  N  )  .LE.  -1 

.And.  .NOT.  ERROR  .AND.  SORTED  (  ARRAY  •  LENGTH  )  .AND.  X  >  ARRAY  (  ( 

N  «  R  )  /  2  )  .GT.  0  .And.  .  N  ♦  R  .lt.  -1  .AND.  |  X  •  ARRAY  (  M  >  .6 

T.  0  «CR.  X  -  ARRAY  (  R  )  .EO.  0  )  .AND.  .N«l  (N«M)/2>.|T. 

•1  .IRP.  X  -  ARRAY  (  I  N  ♦  M  )  /  2  >  .GT.  0  >  .OR.  (  X  -  ARRAY  <  N  >  . 

LE.  -1  .ANC.  .NOT.  ERROR  .AND.  SORTED  (  ARRAY  «  LENGTH  )  .AND.  X  •  ARR 

at  (  (  N  «  R  )  /  2  )  .GT.  0  .AND.  •  N  ♦  R  *lT.  •!  .AND.  (  X  «  ARRAY  ( 

R 

o 
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VLGl/iXlU^  f  2, 


SUBHOUTINC  L'lMbCH  (  ARRAY*  LLNGTMi  X«  LOOKUP*  LRRCK  I 


FficcF  CF  verification  CONCITION  CCWFLETEU 
LSIkG  the  following  AXXORS  2 


VLG*FATu  =  R«2«5*7*id 


SOUROUTINE  OlNiiCH  (  ARRAY*  LENGTH*  X*  LOOKuP*  ERROR  ) 


PATH  SOURCE  TEXT 


IV 

while  (  a  «  1  .LT.  N  ) 

20 

( 

1) 

.  ASSLrT  (  (  M  .LT.  N 

.ANn.  SURTED 

*,  ARRAY  (  F  )  .LE.  X  . 

A  k 

AND.  X  .LT. 

21 

< 

1  > 

•  •  1 

.  1  =  (  R  •»  N  >  /  2 

22 

( 

1 ) 

.  IF  (  X  .LT.  ARRAY  I 

1  )  : 

29 

( 

1) 

.  ORIF  (  X  .GT.  array 

(  I  )  ) 

2f 

ELSE 

27 

( 

1 1 

.  LOOKUP  =  1 

26 

( 

1) 

.  K  =  1 

29 

t 

1) 

.  N  =  1  ♦  1 

30 

LNDIF 

31 

ENLWHILE 

19 

I.HILE  1  R  4  1  .LT.  N  ) 

20 

ASSERT  (  (  K  .LT.  N  .AND.  SORTED  1 

*ARRAY  <  ¥  )  .LE.  X  .ARC.  X  .LT.  ARRAY  (  N  )  >  .AND.  .NOT.  ERROR  ) 

•  J 


verification  condition  subroutine  BlNSCH  (  array*  LENGTH*  X*  LOOKUP*  ERROR  > 

line  verification  CONCITION 

19  K  4  1  .LT.  N 

AND 

20  K  .LT.  N  .and.  SORTED  <  ARRAY  «  LENGTH  >  .AND.  ARRAY  (  R  )  .LE.  X  .AnO 
.  X  .LT.  ARRAY  (  N  I  .AND*  .NUT.  ERROR 

AND 

22  X  .GE.  array  (  (  H  ♦  N  >  /  2  ) 

AND 

29  X  .LE.  array  (  I  M  »  N  )  /  2  ) 

AND 

19  (<H«N)/2)*1  .LT.  (  (  M  «  N  >  /  2  )  ♦  1 

- - - IKPLIES . . . - - - 


20  (  K  «  N  )  /  2  .LT.  (  (  K  «  N  }  /  2  )  «  1  .AND.  SORTED  (  ARRAY  «  LENGTH 

)  .AND.  ARRAY  (  I  R  «  N  )  /  2  )  .LE*  X  .AND*  X  .LT*  ARRAY  (  (  (  M  ♦  N 

)  /  2  )  >  1  )  .And*  •noy*  error 
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V 


SUD'<00T1N£  blN&Ch  (  ARKAr.  LtNGTH.  X,  LCOKllPt  CRROR  ) 


PRCCF  OF  VtRlFlCATlCN  COKDITION  COMFLLTFD 


V(.GfP«TH  =  J'2**4t3  SUbl<CUTl(.E  bIMSCH  (  ARHAy.  LLNGTHf  Xi  LUOKuP«  ERROR  I 


LIM 

HAIM  SuORCt  Text 

19 

hHlLE  (  A  4  1  .LT.  N  ) 

20 

( 

1) 

.  ASSERT  (  <  M  .LT.  N 
4,  array  (  M  )  .LE.  X  . 

*.  ) 

.  I  =  t  P  4  N  )  /  2 

.AND.  sorted  (  ARRAY.  LENGTH  )  )  .AND.  (  ( 
and.  X  .LT.  array  in))  .AnD.  .NOT.  ERROR 

21 

( 

1) 

22 

{ 

1) 

.  IF  (  X  .LT.  array  ( 

1  >  ) 

23 

( 

2) 

.  .  U  =  1 

30 

( 

1) 

.  ENCIF 

31 

LNLUHIuE 

19 

mHILL  (  P  4  1  ,i.T.  N  ) 

32 

ASSERT  (  (  M  .LT.  N  .Ar.O.  SORTED  1  ARRAY.  LENGTH  )  )  .AnD.  (  ( 

4AKRAT  I  P  )  .LE.  X  .ANL 
«) 

.  f.  .LT.  ARRAY  IN))  .AND.  .NOt.  ERROR  ) 

VtPlFlCATlOW  CONUlTiCh  SOBHOUTlNE  blNSCH  (  ARRAy,  LLNGTHi  Xt  LOOKliP,  ERROR  ) 

LINE  VERIFIC.  TiOlv  COROITiCN 

IS  P  ♦  1  ,LT.  N 

AKO 

20  H  .LT,  A  .AND.  SCRTEO  <  ARRAY  .  LENGTH  )  .ANO.  ARRAY  I  M  »  .LE,  X  .AND 
•  X  >17.  ARRAY  (  N  )  .ANCi.  .NuT.  ERROR 

ANC 

22  X  .LT.  array  (  (  N  4  N  )  /  2  I 
ANU 

19  N  4  X  .6E.  (  R  4  N  »  /  2 

. — iXPLlES . . . . 

32  N  .LT.  (  R  4  N  J  /  2  .AND*  SORTED  i  ARRAY  .  LENCtH  »  .AND.  ARRAY  <  M  ) 
.LE.  X  .AND*  X  .LT.  ARRAY  T  (  R  4  N  )  /  2  )  .AND.  .NOT.  ERROR 
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VLG<P/>Th  =  3<2i<4i3  SUBKOuTIN^  blNSCH  (  ARHAYi  LENGTH*  X<  LOOKiiP.  ERROR 

clause  VLKXfiCATiCN  CONOXIION 

1  X  -  ARRAY  <  N  )  ,LT.  0 

AND 

2  ttwY*  CHROR 

AtlQ 

3  SORTED  (  ARRAY  «  LEN6TH  | 

ANC 

4  X  •  ARRAY  (  (  N  ♦  R  I  /  2  )  .LT.  0 

ANU 

a  -  N  ♦  R  .LT.  -1 

AND 

6  -  X  •»  ARRAY  I  R  )  .LC*  U 

AND 


7 

-  (  (  N  4  P  > 

/ 

2 

» 

♦ 

.6C. 

-1 

a 

-  (  (  N  4  K  ) 

t 

2 

» 

4 

M 

.LT. 

0 

entered  expression 

-  ^  (  N  4  P  ) 

t 

2 

I 

4 

PI 

.6E. 

>  1  s  .  N  ♦  M  .6E.  •  2 

rule 

-  (  (  N  4  P  » 

/ 

2 

) 

4 

PI 

.«E. 

•1  B  .  N  t  P  ,6E.  -2 

replace 

-  X  (  N  4  P  ) 

/ 

2 

> 

♦ 

M 

.6E. 

-1  e  .  N  t  p  .gE.  -2 

SAVCO  AS  AXICR  3 
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Vt-G.AxiCN*  SUBROUTINE  BINSCH  (  ARRAy,  LENGTKii  Xt  LOOKiiPt  ERROR  ) 

CLAUSE  VLRIFICATION  CONClTION 

1  X  -  ARRAY  (  N  )  .LT.  0 

ANC 

2  .NOT.  ERROR 

ANC 

3  SCHTEO  <  ARRAY  i  LENGTH  > 

ANO 

4  X  -  ARRAY  «  (  N  ♦  R  »  /  2  »  .LT.  0 

ANU 

5  -  N  ♦  R  .LT.  -1 

< 

ANO 

t  •  X  *  ARRAY  (  R  )  .LE.  0 

ANC 


7 

-  N  ♦  R  .GE.  -2 

irrLAtS  •••••••■ 

-  <  (  N  ♦  R  1  /  2 

>  ♦  M 

.LT.  0 

enterec  expression 

• 

PXl  .LT.  -  1  «  PXI 

.LE. 

•  2 

rule 

PXl  .LT.  -1  «  PXl 

.LE. 

-2 

replace 

-  N  ♦  R  .LT.  -I  * 

-  N  ■» 

R  .LE«  *2 

saved  as  AXICR  4 


VtGiAXIGV 


suenouTiNC  uinsch  (  arrayi  llngth*  x«  lookuPi  error  > 


clause  VERlFICATlCU  COhOUlCN 

1  X  -  array  (  N  )  .LT«  0 

ANL 

2  •AOr.  tRROR 

ANC 

3  SORTED  (  ARRAY  «  LEK6TH  ) 

ANU 

M  X  -  array  (  (  N  «  K  )  /  2  )  .LT*  0 

AND 

5  -  N  ♦  K  .LC.  -2 

and 

6  -  X  >  ARRAY  (  R  )  .LE*  0 

AMD 

7  -  N  ♦  R  .GCf  -2 
....L......  iKPLUS 

e  -((N^R)/2)<»R  .tT.  0 

entered  EXPRESSION 

•  N  >  R  .LE.  •  2  tANO*  Pxl  •AND.  .  N  «  R  .6C>  •  2  «  •  N  t  M  tEfi.  •  2  (AND*  PXl 

role  (  -  N  «  R  .to*  -2  .AND*  PXl  )  s  (  «  N  ♦  R  .EC.  >2  .AND.  PXl  ) 

NO  HEPlACERENTS  PEKFORREC 
ENTERED  EXPRESSION 
N  ■  R  ♦  2 

role  N  s  (  2  ♦  R  ) 

replace  N  »  2  ♦  R 

replace  N  s  2  4  K 

replace  N  s  (  2  4  R  ) 

replace  N  X  (  2  ♦  R  ) 

replace  N  ■  2  «  M 


D-46 


VCGiRt^LACt.  SlJbKOUTlNL  MlK&CH  (  AKHAYt  LCNGTHt  X«  LOOKllPt  ERROR  ) 

CtALSE  VERIFltATlLN  tONElTION 

1  •NOT«  LKROH 

AND 

2  SORTEC  I  AHHAT  i  LEAGIH  ) 

A  NO 

3  X  -  ARRAY  (  2  4  R  )  .ET.  0 

ANO 

^  X  -  ARRAY  (  (  2  ♦  K  ♦  M  >  /  2  »  .lT.  0 
ANO 

5  -  X  4  ARRAY  (  R  )  .LE.  0 

...........  IMPLIES  -  -  -  - - — 

6  -((24R4R)/2»4R.LT.0 
cnter^o  expression 

<(24f«4R)/2)=R4l 

RULE  «  (24R.  4R)/2»sjl4R) 

replace  (24R4R  )/2s14r 

replace  I  (24R4M)/2>>i(l4R> 


VCGiREPlACE.  SObHOUTlNE  BlN&CH  (  ARKAYi  LENGTHi  X<  LOOKliP.  ERROR  ) 

PROOF  OF  VEHlFlCATiON  LONOIIION  COrPLLYEO 
LSINS  the  following  AxiORS  3  H 


YCGfPATH:G<2<9«6«3 


SUPROUTIhE  blNSCH  I  ARRAy,  LENGTH.  X.  LOOKuP.  ERROR  > 


o 


LINE 

PATH  SOORCE  TEXT 

19 

WHILE  (  R  4  1  .tT.  N 

20 

( 

1) 

.  assert  (  (  R  .LT. 

4.  array  I  R  )  .LE. 
4.  ) 

21 

1 

1) 

.  I  4  I  R  4  N  )  /  2 

22 

I 

1) 

.  IF  1  X  .LT.  ARRAY 

24 

URIF  I  X  .6T.  array 

25 

1 

1) 

.  R  «  X 

30 

ENUIF 

31 

ENObHILE 

19 

WHILE  I  R  4  1  .LT.  N 

32 

assert  I  t  R  .LT.  N 

N  .AN(<«  SORTEC  (  ARRAY.  LENGTH  )  >  .ANO*  (  ( 


aAKHAV  (  R  )  .LE.  X  .AND*  X  .LT.  ARRAY  IN))  .AND.  .NOT.  ERROR  ) 

4) 
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VtRIFICATlUN  CUNClTlCN  SUbROOTlNL  (  ARKAy.  LCNGTHi  X«  LOOKtiPi  ERROR  I 

LINE  VLRiFlCATlCN  LOWLITIUN 

19  M  ♦  1  .LT.  N 

ANO 

20  R  .LT.  N  •and.  SCRUO  (  ARRAY  .  LCrJbTH  >  .AND*  ARhAY  (  H  )  .LE.  X  .AND 
.  X  .LT.  ARRAY  (  N  )  .ANC.  .NOT.  ERROR 

AND 

22  X  .6E.  ARRAY  (  (  M  «  N  )  /  2  ) 

ANU 

29  X  .GT.  array  (  (  M  ■»  N  )  /  2  ) 

AND 

19  (  (  K  *  N  )  /  2  )  4  1  .6L.  h 

— - -  implies  — - - - - 

32  (  M  4  R  }  /  2  .LT.  N  •ANC.  SORTED  I  ARRAY  «  LENGTH  >  .AND.  ARRAY  (  (  M 

4  N  )  /  2  )  .LC.  X  •AND.  X  .LT.  ARRAY  (  N  )  .AND.  .NOT.  ERROR 


) 


) 
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V«.Gi^ATH=‘**2'5.to.3  SUDROUTRE  aiNSCH  (  ARRAV,  LENGTHi  X,  LOOKUP* 

CLAUSE  VEHiUCATlCN  CONOIUOK 

1  X  -  ARRAY  (  N  )  .LT.  0 
ANU 

i  .NCI.  ERROR 

ANO 

3  SORTLC  <  ARRAY  *  lEAGTH  ) 

AND 

^  X  •  array  <  (  N  ♦  R  )  /  2  )  .GT.  0 

AND 

5  -  N  ♦  F  .LT,  *1 

AND 

6  •  %  *  ARRAY  (  F  )  .LE.  0 

AMO 

7  .n+<(N^F>/2J  .6L.  -1  ■ 

.  IFPLIES  . — — — . — — . — — . 

6  •N>({N+F|/2)  .LT •  0 

AND 

5  •  X  ♦  ARRAY  <  (  N  ♦  F  I  /  2  )  .LE*  0 

ent£hco  exprlssxcn 


•  N 

♦ 

( 

( 

N 

♦ 

F 

» 

/ 

2 

» 

.GE. 

-  1  r  -  N  ♦  F  .GE.  -  2 

rule 

-  N 

♦ 

( 

( 

N 

♦ 

F 

) 

i 

2 

» 

.6E. 

-X  e  -  N  ♦  F  .GE.  -2 

replace 

•  N 

« 

( 

N 

♦ 

F 

» 

/ 

2 

1 

.GE. 

>1  B  -  N  ♦  F  .GE.  >2 

•V 


VtOtREPL^Ct*  S'JtlKOkJT IivL  BIMSCH  (  4RhAYi  LENGTH*  X*  LOOKUP*  ERROR  ) 

CLAUSE  VEHlMLATlCN  CONOlTiON 

1  X  -  ARRAY  (  N  )  .LT*  0 

ANU 

2  •NOT*  ERROR 

Al' 

3  SORTED  (  ARRAY  «  LEKOTH  I 

AND 

H  X  •  ARRAY  (  (  N  ♦  K  )  /  2  )  .6T.  U 
mnu 

5  -  N  ■»  K  .LT.  -1 

ang 

«  •  t  *  array  (  R  I  .LE.  0 

ANC 

7  -  N  4  R  .GE.  -2 

. IRPLitS  — - . — — - — . - . 

a  •N'»((N«K)/2).L1.0 

AND 

9  -  X  >  ARRAY  (  (  N  ♦  R  I  /  2  )  tLc.  0 

USING  AXIOM  4 

RULE  PXl  •LT*  '1  >  PXX  .LE.  -2 

REPLACE  -  N  ♦  R  .LT.  -1  *  -  N  ♦  R  .LE.  -2 
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V(-GtAXIC?'«'».  SUBROUTInC  BlNiiCH  (  ARKAy,  L£N6TH.  X«  LOOKliP.  tiRROH  ) 

CLAtSC  VCRIFICATICN  CONQlTlOh 

1  X  •  ARRAY  <  N  )  •LT>  0 

ANU 

2  •r^OTi  LRROR 

ANU 

3  SOKTLG  (  ARRAY  .  UK6TH  ) 

ANU 

H  X  -  array  (  (  N  «  K  I  /  2  )  .ST.  0 
AND 

5  -  N  ♦  R  .LE.  -2 

ANU 

6  -  X  4  ARRAY  (  R  )  .lC.  0 

ANO 

7  •  N  ♦  R  «GE.  *2 

. —  IRHLiES  — — . 

a  -N4i(NARW«»  U 

AtlO 

$.  -  X  ♦  ARRAX  ^  (  N  A  «  X  /  2  S 

C^X(HCU  EXPHESSXOR 
N  *  R  ♦,  2 

R*.tE  N  s  (  2  4  K  X 

RtPtACE  N  s  2  4.  M 

replace  N  »  2  ii  N 

replace  N  s  I  2  a  P  X 

replace  N  s  L  2  4|  R  X 

replace  N.  a  E  2  d  K  X 

replace  N  a  2  ^  M 

replace  N  a  2  a  M 
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VtGtKEf’LflCt 


SI-BKCUTIKE  BIMSCH  (  AKRAt*  LENGTH*  X*  LOOKuF*  ERROR  ) 


) 


CLAUSE  VERIEICAtION  LONOlTiON 

1  tNOr.  ERROR 

ANU 

2  SORTED  (  APRAT  •  LEN6TH  ) 

AND 

:  X  •  array  (  2  ♦  r  )  .lt.  0 

and 

4  X  -  ARRAY  (  (  2  ♦  R  ♦  K  »  /  2  }  .GT 
AND 

!  -  X  «  array  I  R  >  .LE.  0 

...........  if<, plies  ------------------ — --- 

i  -R4((2*R*R»/2»  .LT.  2 

and 

7  -  X  ♦  array  <<24R^R>/2). 

entered  expression 

(  (2  +  M  +  M»/2»sR*l 

RLLE  <  (2*H*R»/2)*(1^R) 

replace  (2*R'*R)/2*1  +  H 

replace  <  <2  +  R<*RI/2»»l+R 

replace  I2*R'»RW2*1-»R 


LE.  0 

) 


1 
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VLGiKEPlACL.  S^BHOUTInE  BINSCH  (  ARHAy,  LLNGTHi  Xt  LOOKltP*  ERROR 

clause  verification  COnciTICN 

1  .NOT.  ERROR 

anu 

2  Sorted  (  array  .  length  i 

ARC 

3  X  •  ARRAY  (  2  ♦  R  )  .LT.  0 

ANO 

H  X  -  array  <  1  «  R  )  .6T.  0 
AND 

!  •  X  •»  ARRAY  I  R  I  .LE.  0 

- iRPLitS - —  -  - - — - .................. - - 

£  -  X  *  ARRAY  (  1  «  M  >  .LE.  U 

entered  expression 


>  X 

*  array  ( 

<  1  ♦ 

R 

)  t  .ue. 

0 

9 

X  .  array 

( 

( 

1 

^  K  )  )  .6T.  0  .OR.  X  . 

(  ( 

I  ♦  M  ) 

)  .EG. 

0 

RLLE 

-  X 

>  ARRAY  ( 

1  <»  R 

) 

.LE.  0  ■ 

1 

X 

«  array  I 

1 

♦ 

¥ 

)  .6T.  0  .OR.  X  •  A 

rray 

(  1  ♦  R 

)  .Eg. 

0 

J 

REPLACE 

•  X 

*  ARRAY  ( 

1  +  R 

) 

.LE.  U  » 

X 

• 

ARRAY  <  1 

♦ 

N 

> 

.6T.  0  .OR.  X  -  ARR 

Ay  <  1  •»  M  )  .eo.  0 


o 
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ARRAY 


VCG.f^EPLACt 


S^OKOUTIKC  BlNSCH  (  ARHAYi  LENGTHt  Xt  LOOKuPi  CRROK  I 


CLAUSE  VERIFlCATlUh  CONDITION 

1  .not.  error 

AND 

2  Sorted  (  array  «  length  > 

AND 

3  X  -  ARRAY  (  2  -»  P  I  .LT.  0 

AND 

4  X  •  array  (  1  «  M  )  .gt.  0 

AND 

5  ••  X  4  ARRAY  (  P  )  .LE.  U 

...........  IrtpLitS - - - - - - - - - 

6  X  -  array  (  1  4  R  )  .GT.  0  .OK.  X  •  ARRAY  I  1  4  r  )  .Eu.  0 

USING  AXIOR  2 

RLlE  ■  <  PXi  .IMP.  PX2  .OR.  PX3  I  s  (  j  PXl  .IP.P.  PX2  )  .OR.  I  PXl  .IPP.  PX3 

)  ) 

replace  (  .NOT.  ERROR  .AND.  SCRTEC  (  ARRAY  <  LENGTH  )  .AnC.  X  -  ARRAY  (  2  4  R 
)  .LT.  0  .ANU.  X  •  ARRAY  <  ],  4  p  I  .GT.  0  .AND.  •  X  4  ARRAY  I  P  )  .LE. 

0  .IPP.  X  -  ARRAY  (  1  4  M  )  .GT.  0  .OR.  X  -  ARRAY  (  1  4  M  )  .EO.  (i  ) 
z  (  (  .not.  EKROR  .ANC.  sorted  (  ARRAY  •  LENGTH  )  .AND.  X  -  ARRAY  (  2 

4  H  )  .LT.  0  .and.  X  •  ARRAY  (  1  4  P  )  .GT.  0  .AND.  •  X  ^  ARRAY  (  p  ) 

.LE.  0  .IMP.  X  •  ARRAY  (  1  4  M  )  .GT.  0  )  .OR.  <  .NOT.  ERROR  .ANO.  SOR 
TED  (  ARRAY  «  length  >  .AND.  X  -  ARRAY  (  2  4  P  )  .LT.  0  .AND.  X  •  aRkA 

Y  (  1  4  p  I  .GY.  U  .and.  •  X  4  array  I  H  )  .LE.  0  .IMP.  X  -  ARRAY  I  1 

4  H  )  .Eq.  0  )  ) 


VLG«AX1CP.2.  subroutine  BlNSCH  (  ARRAY.  LENGTH.  Xi  LOOKUP.  ERRCR  ) 

PROOF  OF  VEHIPICATION  CONDITION  COMPLETED 
USING  THE  POLLOGING  AXIOPS  H  2 
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VtG,P/lTh  =  '**2t5i70 


bUllKCuTIKL  I  AKKAyt  LLNGTH.  X«  LOOKliP.  CRhOK  ) 


line 

PATH  SCURLC  tlx 

19 

LHILE  <  R  4  1  . 

20 

( 

1) 

.  ASSLKT  (  (  H 

•.  ARRAY  (  R  ) 

«.  ) 

21 

( 

1  > 

.  I  =  (  R  4  (g 

22 

< 

1) 

.  IF  (  X  .LT. 

24 

{ 

1) 

.  CRIF  (  X  .GT 

2o 

ELbE 

27 

( 

1> 

.  LOUnlF  3  1 

2b 

« 

1) 

.  R  s  I 

29 

( 

1) 

.  N  =  I  4  1 

30 

ENOIF 

31 

ENORHILE 

19 

rHILE  (  R  4  1  . 

32 

ASSERT  (  (  R  .L 

•LL*  X  tANO*  X  .LT*  ARRAY  (  N  »  I  •AN0>  .N0T>  ERROR  ) 


/  2 


>  ) 

1  )  ) 


«ARRAY  (  A 

•» 


LT.  N  ) 

T.  H  .AND.  SORTED  (  ARRAY*  LENGTH  )  )  .AkD.  (  ( 

)  .lE.  X  (AN’C*  X  •LT.  array  (  N  )  )  .AND*  .NOT*  ERROR  I 


verification  CUNLITICn  SOUNOUTINE  BlNSCH  (  ARRAY*  LENGTH*  X.  lOOKIiP.  ERROR  I 

LINE  verification  CONDITION 

iS  R  ♦  I  .LT.  N 

AND 

20  H  .LT.  N  .ANO.  sorted  (  ARRAY  «  LENGTH  >  .AnO.  ARRAY  (  M  )  .LE.  X  .AND 
.  X  .LT.  ARRAT  <  N  )  .AND.  .NOT.  ERROh 

ano 

22  X  .GE.  array  (  (  M  «  N  t  /  2  ) 

ANC 

24  X  .LE.  array  (  (  M  ♦  N  I  /  2  I 
ANO 

19  ((R«N)/2)«1  .GE.  I  (  R  4  N  >  /  2  I  1 

...........  implies  — —  —  —  - - - - - ......... 

32  (  R  t  N  )  /  2  .LT.  (  (  H  4  N  )  /  2  )  4  1  .AnO.  SORTED  I  ARRAY  .  lEnGTH 

)  .ANC.  ARRAY  (  (  R  4  N  )  /  2  )  .LE.  X  .AND*  X  .lT.  ARRAY  (  (  (  R  «  N 
)  /  2  )  4  1  )  .AND.  .NOY.  ERROH 


(  ) 
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VCG«PATH=‘<’2<S«7>3  SlJ^ROUTlNe  BiMStCH  I  ARHATi  LE.NGTH«  Xi  LOOKUP.  ERROR  ) 

CLAUSE  verification  CONClTtON 

1  X  -  ARRAY  (  N  )  .LT.  0 

ANC 

2  .not.  error 

ANU 

3  SORTED  (  array  «  LENGTH  ) 

ANU 

^  X  -  array  (  (  N  -»  X  )  /  2  )  .LO.  0 
and 

a  -  N  ♦  X  .LT.  -1 

ANU 

6  •  X  ■»  ARRAY  (  X  )  .LE.  0 

- . .  — — — . . . — . . 

7  X  -  array  (l+((N4X»/2»»  ,lT.  0 

anu 

8  •  X  ♦  array  (  (  N  «  M  )  /  2  )  ,U»  0 
ENTCKEO  ExPRtsSlUN 


X 

X 

ARRAY 

< 

« 

X 

♦ 

N 

> 

/ 

2 

RULE 

X 

X 

ARRAY 

{ 

« 

N 

4 

K 

» 

/ 

2 

RtPLACE 

X 

X 

ARRAY 

{ 

( 

M 

4 

R 

) 

/ 

2 

RtPLACE 

X 

X 

array 

{ 

( 

N 

4 

M 

1 

/ 

2 

RtPLACE 

X 

X 

ARRAY 

( 

{ 

N 

4 

R 

1 

/ 

2 

RtPLACE 

X 

X 

array 

( 

( 

N 

4 

R 

I 

/ 

2 

replace 

X 

B 

ARRAY 

« 

( 

N 

4 

H 

1 

/ 

2 
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VtGtKCPLACC.  SUBMCUTINC  81NSCH  (  ARHAy,  LLNGTht  Xi  LOOKliPi  ERKOK  ) 

CLAUSE  VERIFICATICn  COhOlTiCN 

1  .NOT*  ERROR 

AND 

2  SORTED  <  ARRAY  .  LENGTH  ) 

AND 

3  •  ARRAY  (  N  )  «  ARRAY  (  (  N  «  R  )  /  2  )  .lT.  0 

ANO 

-  N  ♦  R  .LT,  -1 

AND 

5  •  ARRAY  (  (  N  «  R  I  /  2  I  ♦  ARRAY  I  R  t  .l£.  0 

...........  Implies  — - - — — — - - - - - 

6  ARRAY  (  (  N  4  M  )  /  2  )  -  ARRAY  (I«((N«K)/2)).LT.0 

entcrcu  Expression 

SCRTED  (  ARRAY  .  LENGTH  »  *  (  ARRAY  I  1  )  -  ARRAY  I  I  ♦  X  »  .LT.  0  )  »ANOt  (  1 
GE.  1  )  .AKC.  (  I  .LT.  LENGTH  ) 

(  \  RLLC  SORTED  (  AkrAY  i  LENGTH  >3(1  .GE.  1  tANC.  ARRAY  (  I  )  •  ARRAY  (  1  * 

1  )  .LT.  0  .AND.  I  •  length  .LT.  0  ) 

replace  sorted  <  ARRAY  .  LENGTH  I  x  I  .GE.  X  .AND.  ARRAY  (  I  )  -  ARRAY  I  1  ♦  1 
I  .LT.  0  •AND*  X  -  LENGTH  .lT.  0 


VCG«NCPLAC£.  subroutine  BlNSCH  (  ARRATi  LENGTHi  Xt  LOOKUP.  ERROR  ) 

CLAUSE  VERIFICATION  LCNUITION 

1  1  .GL.  1 

ANU 

2  AH3AY  J  I  I  -  array  <  1  ♦  1  »  .LT.  U 

AND 

3  I  •  length  .LT.  0 

itt 

ano 

*t  .NOT.  ERROR 

ANC 

9  -  ARRAY  (  N  )  «  ARRAY  (  I  N  4  R  )  /  2  )  .lT.  0 

ANU 

6  -  N  ♦  R  .LT.  -1 

ANU 

7  -  array  <  (  N  ♦  R  )  /  2  )  •»  ARRAY  «  M  )  .lC.  0 

— — - . . . 

a  ARRAY  (  (  N  R  )  /  2  I  •>  ARRAY  (l«((N4R)/2»)  .LT*  0 

ENtCRCU  CXPHESSION 

I  »  (  R.  •»  N  )  /  2 
RLLE  1  s  I  (  N  «  R  )  /  2  I 

RLPlACE  I  s  (  N  4  R  I  /  2 

REPLACE  I  s  (  N  *  R  )  /  2 

replace  X  a  (  «  N  4  R  >  /  2  » 

replace  X  s  (  (  N  4  M  )  /  2  i 


VOGfREPL/tCE.  SUBROUTINE  BXNSCH  I  ARRAY.  LENGTH.  X.  LOOKllP.  ERROR  > 


PROOF  OF  VEHXFXCATiON  CONCITICN  COMPLETED 


VERIFICATION  CONDITIONS  FOR  SQX 


V(-GiPATHs2«lf3  nLUl  FCNCTION  SQX  |  X  ) 

LINE  PATH  SOLhCE  TEXT 

1  peml  function  SUX  (  X  ) 

7  INITIAL  (  X  .GE.  0.0  ) 

6  SQX  =  O.U 

9  IF  (  X  .GT.  O.U  ) 

17  final  (  SQX  •  SQX  -  X  .lE.  U.0o0o03  •  X  > 


VLKIFICATTUN  CCNCITICN  REAL  FUNCTION  sQX  I  X  ) 

line  verification  CONUITION 

7  X  .GE.  0.0 

ANU 

9  X  .LE.  0.0 

...........  implies  . . . . 

17  (  0.0  «  0.0  )  •  X  .LE*  U. 000003  •  X 


VCG.PATHs2«1<3  real  FUNCTION  SOX  (  X  ) 

PRCCF  OF  verification  CONCITION  COMPLETED 


VtG.f  ATh53»l»2i<*  real  function  SOX  (  X  ) 

tif(C  PAIR  bouHCE  Text 


1  HEAL  FUNCTION  SQX  (  X  ) 

7  initial  (  X  .GE.  0.0  ) 

b  SQX  s  0.0 

9  IF  (  X  .OT.  0.0  ) 

10  (  1)  .  Y  s  o.a  *  n  *  1.0 

11  I  I>  •  bHiLt  (  Y  -  X  /  V  .GT.  O.OOUOUl  •  Y  > 

12  •  2*  •  •  ASSERT  <  (  X  .GE.  O.U  »AnC.  Y  .GE.  0.0  )  .AND.  Y  •  Y  ,6T.  X  ) 
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Wtf^IF  IcaTIOM  tONLlTiClj 


hCAL  fUNCTIOtt  bUX  (  X  > 


LIN£  VL^IFICAt^UN  lONUIt^CN 
7  X  .Gi.  U.O 

AND 

S  X  .GT.  0.0 

ANU 

11  I  O.S  •  X  )  «  1.0  -  (  X  /  I  <  0.5  •  X  )  «  1.0  )  )  .6T.  O.OOOOOl  •  I  ( 

0.5  •  X  )  «  1.0  I 

.........  It- PLUS  - - 

12  X  .6L.  0.0  .AaC.  (  0.5  »  X  )  1.0  .GE.  0.0  .AND.  (  I  0.5  *  X  1.0 

>  *  <  <  0.5  •  X  >  ♦  1.0  »  .GT.  X 


VtG.FATHs3«l<2«<t  RtAL  FtNCTlUN  SbX  I  X  ) 

CLALSC  VCKIFICATION  CCNOITION 

1  •  (  0.0000005  «  X  )  ♦  (  0.5  «  X  >  -  I  A  /  (  1.0  ♦  (  0.5  •  X  >  )  i  .6T. 

l.UOOObl 

AND 

2  X  .61.  0.0 

...........  IppLltS  .  .  . . . 

3  •  X  4  <  0,5  •  X  )  ♦  (  0.5  •  X  I  ♦  (  0.25  *  X  •  A  )  .GT*  l.O 

AND 

H  X  .GE.  0.0 

ANO 

5  0.5  •  X  .GC.  1.0 


VCG,PATHsStl,2i5 


KCAL  rcM'TioN  sex  (  X  ) 


LU.C 


PAIH  suc;«ce  UXT 


1 

7 

6 

9 

10  (  1) 
11  (  1) 
17  i  1) 


real  funciiuu  sex  <  x  ) 
initial  (  X  .GL.  0.0  ) 
sex  s  0.0 

IF  <  X  .61.  0.0  I 
.  1  S  0.5  *  X  4  1.0 

.  XHILE  (  Y  -  X  /  y  .61.  0.000001  •  Y  I 

.  final  (  sex  •  sex  -  X  .le.  o.ooooob  •  x  i 
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VtRIFICATIUN  CONDITION  RtAu  FUNCTION  S6X  t  X  ) 

LINE  verification  CONDITION 

7  X  .ce.  0.0 

AND 

9  X  .CT.  0.0 

AND 

11  (  0.3  *  X  )  ♦  1>0  -  (  X  /  (  <  O.S  *  X  )  ♦  1.0  >  >  .LC.  O.OOOOOl  «  (  ( 

O.S  •  X  )  «  1.0  ) 

Implies  - - - - - - - 

17  (  (  I  O.S  «  X  I  ♦  1«0  )  *  (  (  O.S  •  X  )  «  1.0  )  >  -  X  .Lit  O.OOOOO.X  • 

X 


V(.G«PATHs3«1<2«5  R£AL  FUNCTION  SOX  (  X  > 

CLAUSE  VERir  ICATlON  LONCniON 

1  •  (  U.bOOOOUS  *  X  )  *  (  O.S  »  X  >  •  I  X  /  (  I>0  4  (  O.S  •  X  )  >  >  .UL. 

l.OOOOUl 

ANU 

2  X  .(iT.  0.0 

...........  implies . . 

3  •  (  0.000003  •  X  )  4  (  O.S  «  X  I  4  (  0.5  •  X  )  ♦  (| 0.25  *  X  •  X  )  .  X 
.LE«  1*0 


VUGfPATN:<2ti«<9  HEAL  FUNCTION  bWX  I  X  > 

LINE  PAIP  SOURCE  TEXT 

♦  T  .  G  T .  X  f 

•  Y  .GT.  X  ) 


11  fcHiLE  I  T  •  X  /  Y  .OT.  O.UOUUOl  *  Y  ) 

12  (  1»  .  ASSENT  (  (  X  .bL.  U.O  .AImU*  Y  .GE.  0.0  )  .AND.  Y 

13  i  i»  .  Y  s  0.5  •  «  Y  4  X  /  y  ) 

14  ENLXHILE 

11  khlLE  (  T  •  X  /  Y  .GT.  O.OOUCOl  •  Y  ) 

12  <  1)  .  ASSERT  (  (  X  .6E.  0.0  .ANC.  Y  .GE.  0.0  >  .ANU.  Y 


) 
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'fi;y  'v  '  aif 


VtRIFlCATlUh  CONOITICN 


rlal  fonction  sox  (  X  ) 


LINE  VEHIFXCAtIUN  CONCltlUN 

11  Y  >  (  X  /  Y  )  .61.  J.UOUOOl  •  Y 

ANC 

12  X  .6L.  0.0  .AkC.  Y  .(it.  0.0  .AI.C>  Y  •  Y  .bT.  X 

ANO 

11  (0.b»(Y4»X/Y»ll-i)C/<0.9*IYf<X/Y»» 

O.OOOOOl  •  U.S  •  (  Y  «  (  X  /  Y  )  ) 

■ . . . — . - . - . — — — 

12  X  .6E.  0.0  .ANC.  0.5  •  (  Y  «  (  X  /  Y  )  )  .6C.  0.0  •AND.  0.5  • 
X/Y>»*O.S*IY«(X/y>)  .GT.  X 


V(.GiPATHB2fH«<4  real  FCNCTlON  SOX  (  X  I 

CLAUSE  VEKIFICATICN  CONDITION 

1  X  .GE.  0.0 

ANO 

2  •  (  0.0000005  •  Y  I  •  (  0.0000005  •  I  X  /  Y  >  >  «  (  0.5  •  Y  1 

*(X/Y)i><X/((  0.5  •  Y  )  ♦  (  0.9  «  (  X  /  Y  )  t  >  ! 

ANO 

9  •  (  0.000001  •Yi«Y«IX/Y»  .GY.  0 

ANO 

b  .  X  ♦  (  Y  •  Y  I  .GT.  0 

ANU 

5  Y  .GE.  0.0 

. -  IMPLIES - - - - . — . . . 

S  (  0.5  «  Y  )  ♦  (  0.9  «  (  X  /  Y  )  )  .GE.  0.0 

ANO 

7  •  X  ♦  I  0.25  «  Y  «  Y  >  »  (  0.25  •  Y  •  (  X  /  Y  )  )  «  (  0.25  • 

•  Y  )  «  (  0.29  «(X/Y)«(X/Y)  )  .GT.  0 
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»  »  .GT. 


(  Y  ♦  i 


*  (  n.5 
.GT.  0 


<  X  /  Y  > 


V(-GiPATh's2«‘<'5  KLAL  KOhLTION  SbX  (  X  ) 


LINE 

PATH  SoLHCE 

TEXT 

11 

LHILE  (  Y  - 

X  /  r  .GT. 

O.UouOOl  •  Y  ) 

12  ( 

1) 

.  ASSbhT  ( 

(  X  .Gt  .  u 

. ii  .AwO.  Y  .GE.  0.0 

13  ( 

1) 

.  Y  =  O.S  « 

<  Y  4  X  / 

Y  ) 

14 

LiTUkHILE 

11 

nHILE  I  Y  - 

X  /  Y  .G'. 

O.OoOOOl  «  Y  > 

17 

FINAL  (  SOX 

*  SOX  -  X 

.LE.  0.000003  •  X  ) 

VtRlFICATlON  COUClTlON  REAL  FUr^CTION  :>OX  (  X  i 

LINC  VCRlFlCATlUN  CUMCITIUK 

11  Y  •  (  X  /  Y  >  .GT.  0.000001  *  Y 

AND 

12  X  .OE.  0.0  .AUC.  Y  .6E.  0.0  .aNU.  Y  *  Y  .oT.  X 

AND 

11  (  0.5  *  (  Y  ♦  (  X  /  Y  »  )  I  -  «  X  /  1  U.5  •  (  Y  ♦  <  X  /  Y  )  )  )  ) 

0.000001  «  O.S  *  (  Y  «  (  X  /  Y  )  ) 

...........  i>(>LltS  .  . . . 

17  (0,5*(Y4«X/Y>)*0.5*«Y+JX/Y)))-X  .LE.  0. 

3  •  X 


VOGtHAThsZtOiS  real  Fl'NCTlOM  SUX  (  X  ) 

CLALSC  VCKXFICATICN  CONCITION 

1  X  .GE.  0.0 

AND 

2  -  <  O.OOOUOOS  •  Y  )  '  (  O.UUUUOOs  •  I  X  /  Y  )  )  ♦  (  0.5  *  Y  >  «  ( 
•  <  X  /  Y  )  )  •  (  X  /  (  I  0.9  *  Y  >  ♦  I  O.S  •  (  X  /  Y  )  )  )  )  .LE 

Ar«D 

3  -  (  0.000001  «Y)«Y-(X/YI  .GT.  0 

AND 

»*  -  X  ♦  «  Y  •  Y  )  .«T.  0 

ANJ 

9  Y  .GE.  0.0 

. —  IRPCILS . . . . 

6  .  (  0.000003  •  X  )  .  X  ♦  (  0.29  *  Y  •  Y  )  4  (  0.2S  *  Y  *  (  X  /  Y 

(  0.2S  «  (  X  /  V  )  •  Y  )  4  I  U.29  •IX/'V)*(X/V))  .LE. 


.le. 


OnOoO 


n.5 

.  0 


)  )  4 

n 
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